Update content to call the new template for event definitions

content/client-server-api/_index.md

@@ -1111,7 +1111,7 @@ which has no `m.identity_server` account data event should not end up
 with the client's default identity server in their account data, unless
 the user first visits their account settings to set the identity server.
 
-{{m\_identity\_server\_event}}
+{{% event event="m.identity_server" %}}
 
 ## Capabilities negotiation
 
@@ -1385,14 +1385,12 @@ available room versions.
 
 Room events are split into two categories:
 
-State Events  
-These are events which update the metadata state of the room (e.g. room
+* **State events**: These are events which update the metadata state of the room (e.g. room
 topic, room membership etc). State is keyed by a tuple of event `type`
 and a `state_key`. State in the room with the same key-tuple will be
 overwritten.
 
-Message events  
-These are events which describe transient "once-off" activity in a room:
+* **Message events**: These are events which describe transient "once-off" activity in a room:
 typically communication such as sending an instant message or setting up
 a VoIP call.
 
@@ -1416,11 +1414,15 @@ assuming the client has access to the `com.example` namespace.
 Note that the structure of these events may be different than those in
 the server-server API.
 
-{{common\_event\_fields}}
+#### Event fields
 
-{{common\_room\_event\_fields}}
+{{% event-fields event_type="event" %}}
 
-#### State Event Fields
+#### Room event fields
+
+{{% event-fields event_type="room_event" %}}
+
+#### State event fields
 
 In addition to the fields of a Room Event, State Events have the
 following fields.
@@ -1460,15 +1462,15 @@ This section is a work in progress.
 This specification outlines several standard event types, all of which
 are prefixed with `m.`
 
-{{m\_room\_canonical\_alias\_event}}
+{{% event event="m.room.canonical_alias" %}}
 
-{{m\_room\_create\_event}}
+{{% event event="m.room.create" %}}
 
-{{m\_room\_join\_rules\_event}}
+{{% event event="m.room.join_rules" %}}
 
-{{m\_room\_member\_event}}
+{{% event event="m.room.member" %}}
 
-{{m\_room\_power\_levels\_event}}
+{{% event event="m.room.power_levels" %}}
 
 #### Historical events
 
@@ -1682,7 +1684,7 @@ the topic to be removed from the room.
 
 #### Events
 
-{{m\_room\_redaction\_event}}
+{{% event event="m.room.redaction" %}}
 
 #### Client behaviour
 

content/client-server-api/modules/dm.md

@@ -19,7 +19,7 @@ whether a chat is 'direct' to an invitee.
 
 #### Events
 
-{{m\_direct\_event}}
+{{% event event="m.direct" %}}
 
 #### Client behaviour
 

content/client-server-api/modules/end_to_end_encryption.md

@@ -466,11 +466,11 @@ process.
 
 After the handshake, the verification process begins.
 
-{{m\_key\_verification\_request\_event}}
+{{% event event="m.key.verification.request" %}}
 
-{{m\_key\_verification\_start\_event}}
+{{% event event="m.key.verification.start" %}}
 
-{{m\_key\_verification\_cancel\_event}}
+{{% event event="m.key.verification.cancel" %}}
 
 ##### Short Authentication String (SAS) verification
 
@@ -634,13 +634,13 @@ following error codes are used in addition to those already specified:
 -   `m.mismatched_commitment`: The hash commitment did not match.
 -   `m.mismatched_sas`: The SAS did not match.
 
-{{m\_key\_verification\_start\_m\_sas\_v1\_event}}
+{{% event event="m.key.verification.start$m.sas.v1" %}}
 
-{{m\_key\_verification\_accept\_event}}
+{{% event event="m.key.verification.accept" %}}
 
-{{m\_key\_verification\_key\_event}}
+{{% event event="m.key.verification.key" %}}
 
-{{m\_key\_verification\_mac\_event}}
+{{% event event="m.key.verification.mac" %}}
 
 ###### HKDF calculation
 
@@ -1355,17 +1355,17 @@ messages.
 
 ##### Events
 
-{{m\_room\_encryption\_event}}
+{{% event event="m.room.encryption" %}}
 
-{{m\_room\_encrypted\_event}}
+{{% event event="m.room.encrypted" %}}
 
-{{m\_room\_key\_event}}
+{{% event event="m.room_key" %}}
 
-{{m\_room\_key\_request\_event}}
+{{% event event="m.room_key_request" %}}
 
-{{m\_forwarded\_room\_key\_event}}
+{{% event event="m.room_key" %}}
 
-{{m\_dummy\_event}}
+{{% event event="m.dummy" %}}
 
 ##### Key management API
 
@@ -1451,4 +1451,4 @@ by including a `withheld` property in the `m.forwarded_room_key` message
 that is an object with the `code` and `reason` properties from the
 `m.room_key.withheld` message.
 
-{{m\_room\_key\_withheld\_event}}
+{{% event event="m.room_key.withheld" %}}

content/client-server-api/modules/guest_access.md

@@ -32,7 +32,7 @@ rather than allowing all homeservers to enforce the rules on each other.
 
 #### Events
 
-{{m\_room\_guest\_access\_event}}
+{{% event event="m.room.guest_access" %}}
 
 #### Client behaviour
 

content/client-server-api/modules/history_visibility.md

@@ -43,7 +43,7 @@ setting at that time was more restrictive.
 
 #### Events
 
-{{m\_room\_history\_visibility\_event}}
+{{% event event="m.room.history_visibility" %}}
 
 #### Client behaviour
 

content/client-server-api/modules/ignore_users.md

@@ -11,7 +11,7 @@ and servers can implement the ignoring of users.
 
 #### Events
 
-{{m\_ignored\_user\_list\_event}}
+{{% event event="m.ignored_user_list" %}}
 
 #### Client behaviour
 

content/client-server-api/modules/instant_messaging.md

@@ -11,9 +11,9 @@ room itself such as a room name and topic.
 
 #### Events
 
-{{m\_room\_message\_event}}
+{{% event event="m.room.message" %}}
 
-{{m\_room\_message\_feedback\_event}}
+{{% event event="m.room.message.feedback" %}}
 
 Usage of this event is discouraged for several reasons:  
 -   The number of feedback events will grow very quickly with the number
@@ -24,13 +24,13 @@ Usage of this event is discouraged for several reasons:
 -   There are no guarantees that the client has seen the event ID being
     acknowledged.
 
-{{m\_room\_name\_event}}
+{{% event event="m.room.name" %}}
 
-{{m\_room\_topic\_event}}
+{{% event event="m.room.topic" %}}
 
-{{m\_room\_avatar\_event}}
+{{% event event="m.room.avatar" %}}
 
-{{m\_room\_pinned\_events\_event}}
+{{% event event="m.room.pinned_events" %}}
 
 ##### m.room.message msgtypes
 
@@ -116,7 +116,7 @@ extensible message formatting options, such as the proposal
 [MSC1767](https://github.com/matrix-org/matrix-doc/pull/1767).
 {{% /boxes/note %}}
 
-{{msgtype\_events}}
+{{% msgtypes %}}
 
 #### Client behaviour
 

content/client-server-api/modules/moderation_policies.md

@@ -97,11 +97,11 @@ rules against rooms can describe a room ID or room alias - the
 subscriber is responsible for resolving the alias to a room ID if
 desired.
 
-{{m\_policy\_rule\_user\_event}}
+{{% event event="m.policy.rule.user" %}}
 
-{{m\_policy\_rule\_room\_event}}
+{{% event event="m.policy.rule.room" %}}
 
-{{m\_policy\_rule\_server\_event}}
+{{% event event="m.policy.rule.server" %}}
 
 #### Client behaviour
 

content/client-server-api/modules/presence.md

@@ -30,7 +30,7 @@ enum of one of the following:
 
 #### Events
 
-{{presence\_events}}
+{{% event-group group_name="m.presence" %}}
 
 #### Client behaviour
 

content/client-server-api/modules/push.md

@@ -666,7 +666,7 @@ When a user changes their push rules a `m.push_rules` event is sent to
 all clients in the `account_data` section of their next `/sync` request.
 The content of the event is the current push rules for the user.
 
-{{m\_push\_rules\_event}}
+{{% event event="m.push_rules" %}}
 
 ###### Examples
 

content/client-server-api/modules/read_markers.md

@@ -24,7 +24,7 @@ The fully read marker is kept under an `m.fully_read` event. If the
 event does not exist on the user's account data, the fully read marker
 should be considered to be the user's read receipt location.
 
-{{m\_fully\_read\_event}}
+{{% event event="m.fully_read" %}}
 
 #### Client behaviour
 

content/client-server-api/modules/receipts.md

@@ -24,7 +24,7 @@ information on how read receipts affect notification counts.
 Each `user_id`, `receipt_type` pair must be associated with only a
 single `event_id`.
 
-{{m\_receipt\_event}}
+{{% event event="m.receipt" %}}
 
 #### Client behaviour
 

content/client-server-api/modules/room_upgrades.md

@@ -11,7 +11,7 @@ to upgrade to a different room version when needed.
 
 #### Events
 
-{{m\_room\_tombstone\_event}}
+{{% event event="m.room.tombstone" %}}
 
 #### Client behaviour
 

content/client-server-api/modules/server_acls.md

@@ -16,7 +16,7 @@ set of servers, or retroactively make the room no longer federate with
 any other server, similar to setting the `m.federate` value on the
 [m.room.create](#mroomcreate) event.
 
-{{m\_room\_server\_acl\_event}}
+{{% event event="m.room.server_acl" %}}
 
 {{% boxes/note %}}
 Port numbers are not supported because it is unclear to parsers whether

content/client-server-api/modules/server_notices.md

@@ -36,7 +36,7 @@ maximum. New connections are being refused by the server. What defines
 "active" is left as an implementation detail, however servers are
 encouraged to treat syncing users as "active".
 
-{{m\_room\_message\_m\_server\_notice\_event}}
+{{% event event="m.room.message$m.server_notice" %}}
 
 #### Client behaviour
 

content/client-server-api/modules/stickers.md

@@ -22,7 +22,7 @@ when the sticker image is clicked.
 Sticker events are received as a single `m.sticker` event in the
 `timeline` section of a room, in a `/sync`.
 
-{{m\_sticker\_event}}
+{{% event event="m.sticker" %}}
 
 #### Client behaviour
 

content/client-server-api/modules/tags.md

@@ -59,7 +59,7 @@ tags are defined in the `m.*` namespace:
 -   `m.server_notice`: Used to identify [Server Notice
     Rooms](#server-notices).
 
-{{m\_tag\_event}}
+{{% event event="m.tag" %}}
 
 #### Client Behaviour
 

content/client-server-api/modules/third_party_invites.md

@@ -31,7 +31,7 @@ invitee does indeed own that third party identifier. See the
 
 #### Events
 
-{{m\_room\_third\_party\_invite\_event}}
+{{% event event="m.room.third_party_invite" %}}
 
 #### Client behaviour
 

content/client-server-api/modules/typing_notifications.md

@@ -12,7 +12,7 @@ events scoped to a `room_id`. This means they do not form part of the
 
 #### Events
 
-{{m\_typing\_event}}
+{{% event event="m.typing" %}}
 
 #### Client behaviour
 

content/client-server-api/modules/voip_events.md

@@ -15,7 +15,7 @@ send call events to rooms with exactly two participants.
 
 #### Events
 
-{{voip\_events}}
+{{% event-group group_name="m.call" %}}
 
 #### Client behaviour