-We find this door in the café. We must specify the direction in which
-the door leads and, as we have mentioned in the café's description, that
-would be to the north. That’s what the ``door_dir`` property is for, and
-in this case it takes the value of the north direction property
-``n_to``. Then we must tell Inform the identity of the room to be found
-behind the door, hence the ``door_to`` property, which takes the value
-of the toilet room -- to be defined later. Remember the café's
-connection to the north, ``n_to toilet_door``? Thanks to it, Inform will
-know that the door is in the way, and thanks to the ``door_to``
-property, what lies beyond.
-
-Doors *must* have the attribute ``door``, but beyond that we have a
-stock of options to help us define exactly what kind of door we are
-dealing with. As for containers, doors can be ``openable`` (which
-activates the verbs OPEN and CLOSE so that they can be applied to this
-object) and, since by default they are closed, you can give them the
-attribute ``open`` if you wish otherwise. Additionally, doors can be
-``lockable`` (which sets up the LOCK/UNLOCK verbs) and you can make them
-``locked`` to override their default unlocked status. The verbs LOCK
-and UNLOCK are expecting some kind of key object to operate the door.
-This must be defined using the ``with_key`` property, whose value should
-be the internal ID of the key; in our example, the soon-to-be-defined
-``toilet_key`` . If you don't supply this property, players won't be
-able to lock or unlock the door.
-
-This simple door definition has one problem, namely, that it exists only
-in the café room. If you wish the door to be present also from the
-toilet side, you can either (a) define another door to be found in the
-``toilet room``, or (b) make this one a two-sided door.
-
-Solution (a) seems superficially straightforward, but then you have the
-problem of keeping the states of the two doors – open/closed,
-locked/unlocked -- in synch. In this scenario, where you can access the
-toilet only through this door, that wouldn't be too complicated, since
-you could leave the door object in the café room opened all the time,
-regardless of what players do with the door object in the toilet room
-and vice versa -- they are never going to see them at the same time. In
-general terms, though, such inconsistencies lead to problems; solution
+We find this door in the café. We must specify the direction in which the
+door leads and, as we have mentioned in the café's description, that would
+be to the north. That’s what the :prop:`door_dir` property is for, and in
+this case it takes the value of the north direction property :prop:`n_to`.
+Then we must tell Inform the identity of the room to be found behind the
+door, hence the :prop:`door_to` property, which takes the value of the
+toilet room -- to be defined later. Remember the café's connection to the
+north, ``n_to toilet_door``? Thanks to it, Inform will know that the door
+is in the way, and thanks to the :prop:`door_to` property, what lies
+beyond.
+
+.. Generated by autoindex
+.. index::
+ pair: door; library attribute
+ pair: lockable; library attribute
+ pair: locked; library attribute
+ pair: open; library attribute
+ pair: openable; library attribute
+ pair: with_key; library property
+
+Doors *must* have the attribute :attr:`door`, but beyond that we have a
+stock of options to help us define exactly what kind of door we are dealing
+with. As for containers, doors can be :attr:`openable` (which activates
+the verbs OPEN and CLOSE so that they can be applied to this object) and,
+since by default they are closed, you can give them the attribute
+:attr:`open` if you wish otherwise. Additionally, doors can be
+:attr:`lockable` (which sets up the LOCK/UNLOCK verbs) and you can make
+them :attr:`locked` to override their default unlocked status. The verbs
+LOCK and UNLOCK are expecting some kind of key object to operate the door.
+This must be defined using the :prop:`with_key` property, whose value
+should be the internal ID of the key; in our example, the
+soon-to-be-defined ``toilet_key`` . If you don't supply this property,
+players won't be able to lock or unlock the door.
+
+This simple door definition has one problem, namely, that it exists only in
+the café room. If you wish the door to be present also from the toilet
+side, you can either (a) define another door to be found in the ``toilet
+room``, or (b) make this one a two-sided door.
+
+Solution (a) seems superficially straightforward, but then you have the
+problem of keeping the states of the two doors – open/closed,
+locked/unlocked -- in synch. In this scenario, where you can access the
+toilet only through this door, that wouldn't be too complicated, since you
+could leave the door object in the café room opened all the time,
+regardless of what players do with the door object in the toilet room and
+vice versa -- they are never going to see them at the same time. In
+general terms, though, such inconsistencies lead to problems; solution