info: typo + wrapping

Signed-off-by: Mattias Andrée <maandree@operamail.com>

1 files changed, 505 insertions, 556 deletions

diff --git a/doc/info/mds.texinfo b/doc/info/mds.texinfo
index bf26a32..caf880f 100644
--- a/doc/info/mds.texinfo
+++ b/doc/info/mds.texinfo
@@ -264,65 +264,73 @@ libraries and concepts.
 @node Overview
 @chapter Overview
 
-@command{mds}@footnote{mds stands for micro-display server.}
-is a display server protocol and an implementation of said
-protocol. What makes @command{mds} stand out is its core
-design choice: it is desigend just like a microkernel.
-Rather than one, possibly modular, process --- a monolithic
-process --- @code{mds} is comprised of many small servers,
-each exchangable and responsible for one thing.
+@command{mds}@footnote{mds stands for micro-display
+server.} is a display server protocol and an
+implementation of said protocol. What makes
+@command{mds} stand out is its core design choice:
+it is desigend just like a microkernel. Rather than
+one, possibly modular, process --- a monolithic
+process --- @code{mds} is comprised of many small
+servers, each exchangable and responsible for one
+thing.
 
 @cpindex Goals of @command{mds}
-@command{mds}'s goal is neither security, performance nor
-a perfect graphical experience. @command{mds} is all
-about flexibility and freedom 0@footnote{The freedom to run
-the program as you wish, for any purpose.}.
-
-The reason for having a display server architectured as a
-microkernel is so that components can be added, removed,
-updated and replaced online. Additionally, the message passing
-between the servers makes it easy to design a system that
-lets you make clients that can listen on messages between
-the servers and perhaps modify them. This enables you to
-do so much more with your display server. Moreover, if
-a single part of the system crashes it does not bring down
-the whole system, and the crashed server can be respawned
-with minor side effects. @command{mds} is architectured
-in three layers: a microkernel, a master server and a
-collection of servers. And clients are actually located
-on the same layer as the servers, because there is no
-actual difference, the only thing that separates a server
-from a client is for what purpose you run it. @command{mds}'s
-kernel is a minimal program that do initialisation of the
-display, such as giving it an index and create runtime
-files and directories for servers and other programs
-to use. Then the kernel creates a domain socket for the
-master server and spawns the master server and respawns
-it if it crashes. Because of this, if the master server
-crashes it will not lose its socket when it is respawned.
-The master server then, on its initial spawn, starts
-the all servers and other programs that the user have
-choosen and then starts accepting connections to it and
-coordinates messages between servers and clients. Further,
-separating all components into separate processes enables
-us to only give the servers the privileges they actually
-need, rather than having one program with root privileges
-that takes care of everything even things that do not do
-require any privileges.
-
-All @command{mds}'s servers, that is all running parts of
-@command{mds} except the kernel, are designed so that they
-can re-execute themself so that they can be updated online
-without any side effects. Servers serialises their state,
-saves it to RAM (in a directory created by the kernel),
-re-execute themself and loads their serialised state. The
-kernel cannot do this because when it has spawned the
-master server it has no reason to re-execute, its only mission
-is to respawn the master server it if would happen to crash.
-It would technically be possible to enable the kernel to
-re-execute but it is not worth it as there is no reason to
-re-execute, and doing so puts the display server at risk
-of crashing.
+@command{mds}'s goal is neither security, performance
+nor a perfect graphical experience. @command{mds} is
+all about flexibility and freedom 0@footnote{The
+freedom to run the program as you wish, for any
+purpose.}.
+
+The reason for having a display server architectured
+as a microkernel is so that components can be added,
+removed, updated and replaced online. Additionally,
+the message passing between the servers makes it easy
+to design a system that lets you make clients that
+can listen on messages between the servers and
+perhaps modify them. This enables you to do so much
+more with your display server. Moreover, if a single
+part of the system crashes it does not bring down the
+whole system, and the crashed server can be respawned
+with minor side effects. @command{mds} is
+architectured in three layers: a microkernel, a
+master server and a collection of servers. And
+clients are actually located on the same layer as the
+servers, because there is no actual difference, the
+only thing that separates a server from a client is
+for what purpose you run it. @command{mds}'s kernel
+is a minimal program that do initialisation of the
+display, such as giving it an index and create
+runtime files and directories for servers and other
+programs to use. Then the kernel creates a domain
+socket for the master server and spawns the master
+server and respawns it if it crashes. Because of
+this, if the master server crashes it will not lose
+its socket when it is respawned. The master server
+then, on its initial spawn, starts the all servers
+and other programs that the user have choosen and
+then starts accepting connections to it and
+coordinates messages between servers and clients.
+Further, separating all components into separate
+processes enables us to only give the servers the
+privileges they actually need, rather than having
+one program with root privileges that takes care of
+everything even things that do not do require any
+privileges.
+
+All @command{mds}'s servers, that is all running
+parts of @command{mds} except the kernel, are
+designed so that they can re-execute themself so that
+they can be updated online without any side effects.
+Servers serialises their state, saves it to RAM (in a
+directory created by the kernel), re-execute themself
+and loads their serialised state. The kernel cannot
+do this because when it has spawned the master server
+it has no reason to re-execute, its only mission is
+to respawn the master server it if would happen to
+crash. It would technically be possible to enable the
+kernel to re-execute but it is not worth it as there
+is no reason to re-execute, and doing so puts the
+display server at risk of crashing.
 
 
 
@@ -349,18 +357,18 @@ of crashing.
 The @command{mds} display server in architectured in
 three layers. The first layer is called the kernel.
 The kernel is responsible for acquiring a display
-server index@footnote{As with any display server,
-the system can have multiple instances of
-@command{mds} running at the same time.}, set up
-environment variables to indicate which display
-server and display server instance is being used,
-create a domain socket for the display server and
-start the master server and restart it if it crashes,
-and then clean up the system when the display server
-closes. The kernel only responsible for creating
-the domain socket for communication with the display
-server, it is not responsible for using it, that
-mission falls to the master server.
+server index@footnote{As with any display server, the
+system can have multiple instances of @command{mds}
+running at the same time.}, set up environment
+variables to indicate which display server and
+display server instance is being used, create a
+domain socket for the display server and start the
+master server and restart it if it crashes, and then
+clean up the system when the display server closes.
+The kernel only responsible for creating the domain
+socket for communication with the display server, it
+is not responsible for using it, that mission falls
+to the master server.
 
 @cpindex Master server
 @cpindex Message passing, coordination
@@ -372,22 +380,22 @@ server has two responsibilities: coordinating
 message passing between other servers and clients
 @footnote{In @command{mds} there is no functional
 distinction between servers and clients, the
-distinction is purely semantic.} and starting
-other servers.
+distinction is purely semantic.} and starting other
+servers.
 
 @cpindex Starting of servers
 @cpindex Servers, starting
 @pgindex @file{mdsinitrc}
 The third layer is the other servers and clients.
-protocolwise there is no specification on how
-they are started. But in the reference
-implementation of the master server, this is
-done by starting a shell script with the
-pathname @file{$@{XDG_CONFIG_HOME@}/mdsinitrc}
-and the user is responsible for providing the
-logic in that shell script.@footnote{Moonstruck
-users are allowed to implement this in C
-or any other language of their choosing.}
+protocolwise there is no specification on how they
+are started. But in the reference implementation of
+the master server, this is done by starting a shell
+script with the pathname
+@file{$@{XDG_CONFIG_HOME@}/mdsinitrc} and the user
+is responsible for providing the logic in that shell
+script.@footnote{Moonstruck users are allowed to
+implement this in C or any other language of their
+choosing.}
 @c Which is better: cray-cray users, lunatic users,
 @c moonstruck users, insane users, ballers, madmen,
 @c loony tunes, systemd-lovers?
@@ -404,21 +412,18 @@ of the display server.
 @cpindex Interprocess communication, mechanism
 @cpindex Master server
 @pgindex @command{mds-server}
-Intrinsic to @command{mds} is a powerful
-interprocess communication mechanism. Servers
-and clients connect to the display server by
-connecting to a domain socket served by the
-master server. A server or client that has
-connected to the display server can do three
-things:
+Intrinsic to @command{mds} is a powerful interprocess
+communication mechanism. Servers and clients connect
+to the display server by connecting to a domain
+socket served by the master server. A server or
+client that has connected to the display server can
+do three things:
 
 @itemize
 @item
 Request assignment of a unique ID@.
-
 @item
 Multicast a message.
-
 @item
 Join or leave a multicast group.
 @end itemize
@@ -430,15 +435,14 @@ Join or leave a multicast group.
 @cpindex Disconnection
 @cpindex Master server
 @pgindex @command{mds-server}
-Upon assignment of an ID the master server
-will automatically place the client in a
-multicast group for that specific client.
-This automatically multicast group assignment
-is done by the master server simply so you
-as a debugger do not forget to do so. When
-a client is disconnected it will send out a
-message to a specific multicast group that
-the client, refered to by it's ID, have closed.
+Upon assignment of an ID the master server will
+automatically place the client in a multicast group
+for that specific client. This automatically
+multicast group assignment is done by the master
+server simply so you as a debugger do not forget to
+do so. When a client is disconnected it will send
+out a message to a specific multicast group that the
+client, refered to by it's ID, have closed.
 
 @cpindex Message passing, message structure
 @cpindex Communication, message structure
@@ -446,16 +450,16 @@ the client, refered to by it's ID, have closed.
 @cpindex Message structure, message passing
 @cpindex Master server
 @pgindex @command{mds-server}
-A message in the @command{mds} protocol is
-comprised of two parts: headers and a payload.
-When a client joins a multicast group it is
-actually saying that it is interested in
-receiving broadcasts containing a specific header
-or a specific header--value pair, or that it
-is interesting in all messages@footnote{This
-could be used for logging, possibly spying and
-networking.}. Thus a message is automatically
-multicasted to groups indicated by its headers.
+A message in the @command{mds} protocol is comprised
+of two parts: headers and a payload. When a client
+joins a multicast group it is actually saying that
+it is interested in receiving broadcasts containing
+a specific header or a specific header--value pair,
+or that it is interesting in all messages
+@footnote{This could be used for logging, possibly
+spying and networking.}. Thus a message is
+automatically multicasted to groups indicated by its
+headers.
 
 @cpindex Interceptions, message passing
 @cpindex Message passing, message modification
@@ -465,47 +469,41 @@ multicasted to groups indicated by its headers.
 @cpindex Master server
 @pgindex @command{mds-server}
 @cpindex Multicast groups
-The multicast groups and receiving of message
-is called interceptions. The interesting
-property of interceptions is that they may
-be modifying. When a server registers for
-message interception it can say that it wants
-to be able to modify messages. If this is done
-and the server receives a message for which it
-has said it want to be able to modify it,
-the master server will wait for that server
-to respond before it send the message to
-the next server in the interception list.
-The server can choose to do three things
-with a message that it has opted in for
-modification of: leave the message as-is,
-modify the message, or consume the message.
-A message consumption is done by modify
-the message to make it empty. A consumed
-message will not be send to any further
-clients or servers in the interception list.
+The multicast groups and receiving of message is
+called interceptions. The interesting property of
+interceptions is that they may be modifying. When a
+server registers for message interception it can say
+that it wants to be able to modify messages. If this
+is done and the server receives a message for which
+it has said it want to be able to modify it, the
+master server will wait for that server to respond
+before it send the message to the next server in the
+interception list. The server can choose to do three
+things with a message that it has opted in for
+modification of: leave the message as-is, modify the
+message, or consume the message. A message
+consumption is done by modify the message to make it
+empty. A consumed message will not be send to any
+further clients or servers in the interception list.
 
 @cpindex Interception priority, message passing
 @cpindex Priority, interception, message passing
 @cpindex Message consumption, message passing
 @cpindex Consumption, interception, message passing
-To make this mechanism sensible, a server or
-client can set a priority when it registers
-for interception (does not need to be
-modifying.) When a message is broadcasted it
-will be received by all servers in the
-interception except the original sender,
-unless it gets consumes. The order in which
-the master server sends the message to the
-recipients is determined by priority the
-servers registed with. The message first sent
-to the recipients with highest priority and
-last to the recipients with lowest priority,
-and ordered by the priority between those
-priorities. Of two or more servers have the
-same priority the order in which they will
-receive the message, of those recipients,
-is arbitrary.
+To make this mechanism sensible, a server or client
+can set a priority when it registers for interception
+(does not need to be modifying.) When a message is
+broadcasted it will be received by all servers in the
+interception except the original sender, unless it
+gets consumes. The order in which the master server
+sends the message to the recipients is determined by
+priority the servers registed with. The message first
+sent to the recipients with highest priority and last
+to the recipients with lowest priority, and ordered
+by the priority between those priorities. Of two or
+more servers have the same priority the order in
+which they will receive the message, of those
+recipients, is arbitrary.
 
 @pgindex @command{mds-vt}
 @cpindex Virtual terminal, switching
@@ -515,33 +513,29 @@ is arbitrary.
 @cpindex Communication, dual-connection
 @cpindex Interprocess communication, dual-connection
 @cpindex Reflexive connection, message passing
-An interesting property of this mechanism
-is demonstrated in the @command{mds-vt}
-server. Unlike most servers @command{mds-vt}
-maintains two concurrent connections to
-the display. Once @command{mds-vt} receives
-a signal from the OS kernel requesting to
-switch virtual terminal, @command{mds-vt}
-will from one of its connections send
-out a message and wait for it to be
-received in its other connection and the
-let the OS kernel switch virtual terminal.
-The secondary connection to the display
-has registered interception with lower
-priority of the message than the primary
-connection broadcasts. This message will
-be received by other servers that will
-let the message continue to the next
-server in the interception list once that
-server is ready for the OS kernel to switch
-virtual terminal. All of these servers have
-registered modifying interception of the
-message but none of them will actually modify
-or consume the message; it is only used a
-mechanism for letting @command{mds-vt} know
-when all servers are ready for the switch
-without having to know how many they are
-and wait for a reply from all of them.
+An interesting property of this mechanism is
+demonstrated in the @command{mds-vt} server. Unlike
+most servers @command{mds-vt} maintains two
+concurrent connections to the display. Once
+@command{mds-vt} receives a signal from the OS
+kernel requesting to switch virtual terminal,
+@command{mds-vt} will from one of its connections
+send out a message and wait for it to be received
+in its other connection and the let the OS kernel
+switch virtual terminal. The secondary connection to
+the display has registered interception with lower
+priority of the message than the primary connection
+broadcasts. This message will be received by other
+servers that will let the message continue to the
+next server in the interception list once that server
+is ready for the OS kernel to switch virtual
+terminal. All of these servers have registered
+modifying interception of the message but none of
+them will actually modify or consume the message; it
+is only used a mechanism for letting @command{mds-vt}
+know when all servers are ready for the switch
+without having to know how many they are and wait
+for a reply from all of them.
 
 
 
@@ -560,18 +554,18 @@ there are some guildlines you should follow.
 @cpindex Client-side decoration
 @cpindex Server-side decoration
 @cpindex Decoration, guildlines
-@b{Do not create client-side decoration}. Some
-users do not want decorations or wants minimal
-decorations. Windows should look similar, server-side
-decoration helps ensure this. Your client-side
-decorations may not meet the requirements the users
-have. For example, your client-side decoration may
-only support minimise, maximise and close, whilst the
-user may also want, as provided by her decoration
-server, stick, shade and always on top. And it should
-be sufficient to configure your decorations once
-rather once for every toolkit. Additionally, because
-of oversight from developers, client-side decoration
+@b{Do not create client-side decoration}. Some users
+do not want decorations or wants minimal decorations.
+Windows should look similar, server-side decoration
+helps ensure this. Your client-side decorations may
+not meet the requirements the users have. For
+example, your client-side decoration may only support
+minimise, maximise and close, whilst the user may
+also want, as provided by her decoration server,
+stick, shade and always on top. And it should be
+sufficient to configure your decorations once rather
+once for every toolkit. Additionally, because of
+oversight from developers, client-side decoration
 tends to work poorly with tiling window managers.
 
 @item
@@ -582,12 +576,11 @@ tends to work poorly with tiling window managers.
 @b{Do not remember size and position}. Some users
 do not want their programs to remember their size
 and position. There is also a risk that your
-mechanism for implementing this does not account
-for the possibility that outputs may have been
-removed, resized or relocated.
-@command{mds-posmem} can be used if the user wants
-programs to start where they were closed the last
-time they were closed.
+mechanism for implementing this does not account for
+the possibility that outputs may have been removed,
+resized or relocated. @command{mds-posmem} can be
+used if the user wants programs to start where they
+were closed the last time they were closed.
 @end itemize
 
 
@@ -645,16 +638,15 @@ servers collectively.
 @cpindex Version update
 @sgindex @code{SIGUSR1}
 @sgindex @code{SIGUPDATE}
-@command{mds} servers can re-execute into an
-updated version of their binary. This can be
-used to update display server online after
-a new version has been installed. To do this
-send the signal @code{SIGUSR1} to the server
-you want update. If a server does not support
-online updating it will ignore this signal.
+@command{mds} servers can re-execute into an updated
+version of their binary. This can be used to update
+display server online after a new version has been
+installed. To do this send the signal @code{SIGUSR1}
+to the server you want update. If a server does not
+support online updating it will ignore this signal.
 If the operating system defines a signal named
-@code{SIGUPDATE}, this signal is used
-instead of @code{SIGUSR1}.
+@code{SIGUPDATE}, this signal is used instead of
+@code{SIGUSR1}.
 
 @cpindex Signals
 @cpindex Memory release, automatic
@@ -664,11 +656,10 @@ instead of @code{SIGUSR1}.
 @cpindex Releasing memory
 @sgindex @code{SIGDANGER}
 @sgindex @code{SIGRTMIN + 1}
-If you need servers to free up allocated
-memory that they do not use, send the signal
-@code{SIGDANGER}, or if not defined
-@code{SIGRTMIN + 1}. Unimportant servers
-may choose to die on @code{SIGDANGER}@.
+If you need servers to free up allocated memory that
+they do not use, send the signal @code{SIGDANGER}, or
+if not defined @code{SIGRTMIN + 1}. Unimportant
+servers may choose to die on @code{SIGDANGER}@.
 
 @sgindex @code{SIGINFO}
 @sgindex @code{SIGRTMIN + 2}
@@ -676,29 +667,27 @@ may choose to die on @code{SIGDANGER}@.
 @cpindex Statistics dump
 Server may also choose to support the signal
 @code{SIGINFO}, or if not defined
-@code{SIGRTMIN + 2}. It is not expected
-that server do support this signal, but
-thay must not die when received. @code{SIGINFO}
-is send by a user to the server, if she wants
-the server to dump information about the
-server's state or statistics to the TTY@.
+@code{SIGRTMIN + 2}. It is not expected that server
+do support this signal, but thay must not die when
+received. @code{SIGINFO} is send by a user to the
+server, if she wants the server to dump information
+about the server's state or statistics to the TTY@.
 
 @sgindex @code{SIGRTMIN}
 @cpindex No-operation signal
-All servers configured to be interrupted
-when the signal @code{SIGRTMIN} is received.
-No further action is taked. This may be used
-by the user to test that the program supports
-being interrupted. It can also be used by
-the server to interrupt itself from another
+All servers configured to be interrupted when the
+signal @code{SIGRTMIN} is received. No further action
+is taked. This may be used by the user to test that
+the program supports being interrupted. It can also
+be used by the server to interrupt itself from another
 thread.
 
 @pgindex @command{valgrind}
 @sgindex @code{SIGRTMAX}
-@command{valgrind} uses @code{SIGRTMAX} for
-its own internal stuff. Therefore servers must
-not use @code{SIGRTMAX} as it is hence
-unavailable when running under @command{valgrind}.
+@command{valgrind} uses @code{SIGRTMAX} for its own
+internal stuff. Therefore servers must not use
+@code{SIGRTMAX} as it is hence unavailable when
+running under @command{valgrind}.
 
 
 
@@ -710,23 +699,23 @@ unavailable when running under @command{valgrind}.
 @cpindex Kernel
 @cpindex Display server kernel
 @pgindex @command{mds}
-The @command{mds} kernel creates two directories
-for the @command{mds} servers to use: one for
-runtime data and one for temporary data.
-These directories are named by
-@code{MDS_RUNTIME_ROOT_DIRECTORY} and
+The @command{mds} kernel creates two directories for
+the @command{mds} servers to use: one for runtime
+data and one for temporary data. These directories
+are named by @code{MDS_RUNTIME_ROOT_DIRECTORY} and
 @code{MDS_STORAGE_ROOT_DIRECTORY}, respectively,
 by the header file @file{<libmdsserver/config.h>}.
 If the systems runtime data directory is @file{/run}
 and transient temporary data directory is @file{/tmp},
-and the package name of @command{mds} is @command{mds},
-these directories will be @file{/run/mds} and
+and the package name of @command{mds} is
+@command{mds}, these directories will be
+@file{/run/mds} and
 @file{/tmp/.@{system-directory@}.mds}, respectively.
 In @file{/tmp/.@{system-directory@}.mds} the kernel
-will create a directory for the display server instance
-named @file{.data} prefixed by the display server index.
-For example if the display server index is zero,
-temporary data may be stored in
+will create a directory for the display server
+instance named @file{.data} prefixed by the display
+server index. For example if the display server index
+is zero, temporary data may be stored in
 @file{/tmp/.@{system-directory@}.mds/0.data}
 
 @cpindex Re-executing servers
@@ -742,24 +731,22 @@ the POSIX shared memory unit named
 functions for the data type @code{intmax_t}.} is
 replaced with the process ID of the server. This
 file will be bound to the pathname
-@file{/dev/shm/.proc-pid-%ji} if POSIX shared
-memory is stored in @file{/dev/shm} by the
-operating system.
+@file{/dev/shm/.proc-pid-%ji} if POSIX shared memory
+is stored in @file{/dev/shm} by the operating system.
 
-In @code{MDS_RUNTIME_ROOT_DIRECTORY} the kernel
-will create two files. @file{.pid} and @file{.socket},
+In @code{MDS_RUNTIME_ROOT_DIRECTORY} the kernel will
+create two files. @file{.pid} and @file{.socket},
 both prefixed with the display server index
-@footnote{@file{0.pid} and @file{0.socket} if
-the display server index is 0.}. The @file{.pid}
-file contains the process ID of the display server
-and is used by the kernel to figure out whether
-an display server index is still in use or just
-not properly cleaned up. Of course it can be used
-by any program to find the process ID of the
-kernel process of a display server instance.
-The @file{.socket} is the domain socket used
-for communication with the display server and
-its servers and clients.
+@footnote{@file{0.pid} and @file{0.socket} if the
+display server index is 0.}. The @file{.pid} file
+contains the process ID of the display server and is
+used by the kernel to figure out whether an display
+server index is still in use or just not properly
+cleaned up. Of course it can be used by any program
+to find the process ID of the kernel process of a
+display server instance. The @file{.socket} is the
+domain socket used for communication with the display
+server and its servers and clients.
 
 
 
@@ -773,12 +760,11 @@ its servers and clients.
 @cpindex Display server kernel
 @pgindex @command{mds}
 Message passing over domain sockets is the
-underlaying technique for communicating with
-the display server. To communicate with the
-display server in the local machine a process
-must connect to the domain socket created by
-the display server kernel as named in
-@ref{Filesystem}.
+underlaying technique for communicating with the
+display server. To communicate with the display
+server in the local machine a process must connect
+to the domain socket created by the display server
+kernel as named in @ref{Filesystem}.
 
 @cpindex Connecting to the display
 @cpindex Client ID assignment
@@ -800,32 +786,27 @@ Message ID: 0\n
 @cpindex Message ID
 @cpindex Message corruption
 @cpindex Corrupt messages
-where @code{\n} is an LF-line break.
-The value on the @code{Message ID} line
-does not need to be 0, but servers and
-clients often start with 0 and count
-upwards. The value is however bound to
-an unsigned 32-bit integer. All message
-must contain this @code{Message ID} header,
-otherwise the message is considered corrupt
-and is ignored.
+where @code{\n} is an LF-line break. The value on the
+@code{Message ID} line does not need to be 0, but
+servers and clients often start with 0 and count
+upwards. The value is however bound to an unsigned
+32-bit integer. All message must contain this
+@code{Message ID} header, otherwise the message is
+considered corrupt and is ignored.
 
 @cpindex Message structure
 @cpindex Message passing, message structure
 @cpindex Communication, message structure
 @cpindex Interprocess communication, message structure
-The empty line signifies the end of the
-header list, and in this case the end of
-the message. But a message may contain
-payload beneath this empty line. To
-include a payload, add the header
-@code{Length} that says how many bytes
-the payload is comprised.
-
-A header must contain a header name and
-header value without any trailing or
-leading spaces, and `: ' (colon, one
-regular blank space) exactly delimits
+The empty line signifies the end of the header list,
+and in this case the end of the message. But a
+message may contain payload beneath this empty line.
+To include a payload, add the header @code{Length}
+that says how many bytes the payload is comprised.
+
+A header must contain a header name and header value
+without any trailing or leading spaces, and `: '
+(colon, one regular blank space) exactly delimits
 the name and the value.
 
 @cpindex Master server
@@ -834,22 +815,18 @@ the name and the value.
 @cpindex ID assignment
 @cpindex Assignment of ID
 When the master server receives this
-@code{Command: assign-id} message it
-will assign the client a unique ID
-and send it to the client.@footnote{The
-master server is the only server than
-can address the client uniquely before
-it has an ID, so this part can only
-be implement in the master server.}
-If the client already has an ID, it
-will send back that ID to the client.
-This response consists of two headers
-@code{ID assignment} and @code{In
-response to}, containing the client's
-new (or possibly already assigned) ID
-and the value that was in the
-@code{Message ID} header, respectively.
-For example:
+@code{Command: assign-id} message it will assign the
+client a unique ID and send it to the
+client.@footnote{The master server is the only server
+than can address the client uniquely before it has an
+ID, so this part can only be implement in the master
+server.} If the client already has an ID, it will
+send back that ID to the client. This response
+consists of two headers @code{ID assignment} and
+@code{In response to}, containing the client's
+new (or possibly already assigned) ID and the value
+that was in the @code{Message ID} header,
+respectively. For example:
 
 @example
 @group
@@ -860,29 +837,24 @@ In response to: 0\n
 @end example
 
 @cpindex Message ID
-Notice that the master server never
-includes @code{Message ID} in message
-originating from it.
-
-As seen in this example, the client ID
-consists of two integers delimited by
-a colon (`:'). Both of these integers
-are unsigned 32-bit integers. This is
-done this way because unsigned 64-bit
-integers are forbidden because it is
-not supported natively be some
-programming languages.
-
-Before a client has gotten a unique client
-ID assigned to it, it will be `0:0'.
+Notice that the master server never includes
+@code{Message ID} in message originating from it.
+
+As seen in this example, the client ID consists of
+two integers delimited by a colon (`:'). Both of
+these integers are unsigned 32-bit integers. This is
+done this way because unsigned 64-bit integers are
+forbidden because it is not supported natively be
+some programming languages.
+
+Before a client has gotten a unique client ID
+assigned to it, it will be `0:0'.
 
 @cpindex Disconnection
-If a client gets disconnected from the
-master server, the master server will
-sends out a signal header message.
-This header will be @code{Client closed}
-and contain ID of the client that closed.
-For example:
+If a client gets disconnected from the master server,
+the master server will sends out a signal header
+message. This header will be @code{Client closed}
+and contain ID of the client that closed. For example:
 
 @example
 @group
@@ -891,9 +863,8 @@ Client closed: 0:1\n
 @end group
 @end example
 
-Be aware that if a server or client
-closes and does not have a unique client
-ID, this message will be:
+Be aware that if a server or client closes and does
+not have a unique client ID, this message will be:
 
 @example
 @group
@@ -906,21 +877,17 @@ Client closed: 0:0\n
 @cpindex Message passing, addressing
 @cpindex Communication, addressing
 @cpindex Interprocess communication, addressing
-Once a client has an unique client ID
-assigned to it, it should always include
-the header @code{Client ID} in its
-messages. The value of @code{Client ID}
-should be the client's ID@. If a server
-wants to address this client, it should
-include the header @code{To} with the
-value set to the recipient's client ID@.
-Be aware that such message may not be
-sent to that recipient uniquely, any
-server or client is free to sign up
-for receive of such message, any messages
-or message contain any other header or
-header--value pair that may also be
-included in the header.
+Once a client has an unique client ID assigned to it,
+it should always include the header @code{Client ID}
+in its messages. The value of @code{Client ID} should
+be the client's ID@. If a server wants to address
+this client, it should include the header @code{To}
+with the value set to the recipient's client ID@.
+Be aware that such message may not be sent to that
+recipient uniquely, any server or client is free to
+sign up for receive of such message, any messages
+or message contain any other header or header--value
+pair that may also be included in the header.
 
 
 
@@ -939,28 +906,24 @@ included in the header.
 @cpindex Eavesdropping, message passing
 As discussed in @ref{Interprocess Communication},
 interception in the primary feature of
-@command{mds}'s message passing system.
-Not only does it enable servers to select
-which message it wants to receive in order
-to provide it's service. It also enables
-clients to do anything, things that was
-never anticipated. As an example of its
-power, @command{mds} does not provide any
-protocol for taking screenshots or recording
-a session. Instead, a screenshot application
-signs up for messages passed between the
-compositor and presentation servers, and
-simply requests that the compositor resends
-the screen, a feature intended for the
-presentation servers. A screen recoding
-application would do the same and just
-hang on and record all message passed
+@command{mds}'s message passing system. Not only does
+it enable servers to select which message it wants to
+receive in order to provide it's service. It also
+enables clients to do anything, things that was never
+anticipated. As an example of its power,
+@command{mds} does not provide any protocol for
+taking screenshots or recording a session. Instead,
+a screenshot application signs up for messages passed
+between the compositor and presentation servers, and
+simply requests that the compositor resends the
+screen, a feature intended for the presentation
+servers. A screen recoding application would do the
+same and just hang on and record all message passed
 between the servers.
 
-If you want your server or client to
-receive all messages passed around in
-the display server, simply sign up for
-all messages:
+If you want your server or client to receive all
+messages passed around in the display server, simply
+sign up for all messages:
 
 @example
 @group
@@ -970,9 +933,9 @@ Message ID: 0\n
 @end group
 @end example
 
-But if you only want messages contain
-the header @code{Command}, include
-that header in the payload of the message:
+But if you only want messages contain the header
+@code{Command}, include that header in the payload
+of the message:
 
 @example
 Command: intercept\n
@@ -982,9 +945,9 @@ Length: 8\n
 Command\n
 @end example
 
-It is allowed to include multiple headers.
-You can also be more strict, and require
-a specific value for a header, for example:
+It is allowed to include multiple headers. You can
+also be more strict, and require a specific value
+for a header, for example:
 
 @example
 Command: intercept\n
@@ -994,13 +957,13 @@ Length: 16\n
 Command: get-vt\n
 @end example
 
-You may mix these two types of requirements
-freely. Your client will receive any message
-that satisfies at least one of the requirements,
-these requirements may be split into multiple
-message or coalesced into one message; but
-you cannot request to include receive a message
-if multiple requirements are satisfied.
+You may mix these two types of requirements freely.
+Your client will receive any message that satisfies
+at least one of the requirements, these requirements
+may be split into multiple message or coalesced into
+one message; but you cannot request to include
+receive a message if multiple requirements are
+satisfied.
 
 Alternatively you can choose to stop receiving
 message that satisfies requirements. For example:
@@ -1023,16 +986,15 @@ Message ID: 1\n
 \n
 @end example
 
-Note that this will stop you from receiving
-messages contain the @code{To} header addressed
-to you until you request to receiving such
-messages again.
+Note that this will stop you from receiving messages
+contain the @code{To} header addressed to you until
+you request to receiving such messages again.
 
-When you sign up for message you may request
-to be able to modify them before that are
-send to the next client in the list of client
-that should receive them. To do this include
-the header--value pair @code{Modifying: yes}:
+When you sign up for message you may request to be
+able to modify them before that are send to the next
+client in the list of client that should receive
+them. To do this include the header--value pair
+@code{Modifying: yes}:
 
 @example
 Command: intercept\n
@@ -1043,16 +1005,14 @@ Length: 30\n
 Command: keyboard-enumeration\n
 @end example
 
-It is up to the client to keep track of
-which message that it may modify. When
-you receive a message that you can modify
-you must respond when you are done with
-the message.
+It is up to the client to keep track of which message
+that it may modify. When you receive a message that
+you can modify you must respond when you are done
+with the message.
 
-For example, if you have signed up
-for @code{Command: keyboard-enumeration}
-with the ability to modify such messages
-and the message
+For example, if you have signed up for
+@code{Command: keyboard-enumeration} with the ability
+to modify such messages and the message
 
 @example
 Command: keyboard-enumeration\n
@@ -1064,8 +1024,7 @@ Length: 7\n
 kernel\n
 @end example
 
-is send from a server, you may receive
-it as
+is send from a server, you may receive it as
 
 @example
 Command: keyboard-enumeration\n
@@ -1078,23 +1037,19 @@ Modify ID: 4\n
 kernel\n
 @end example
 
-Be aware that the @code{Modify ID} may
-be included even if you have not signed
-up to be able to modify the message,
-it is enough that one client before you
-has or it was originally included
-@footnote{You may however not include
-this header when you send out an
+Be aware that the @code{Modify ID} may be included
+even if you have not signed up to be able to modify
+the message, it is enough that one client before you
+has or it was originally included @footnote{You may
+however not include this header when you send out an
 orginal message.}.
 
-If you receive the message as such
-and want to add the line
-@code{on-screen-keyboard-20376} to
-the payload should send out:
-@footnote{The first line containing
-starting with @code{Message ID} is an
-example, it should be whatever is
-appropriate for your client.}
+If you receive the message as such and want to add
+the line @code{on-screen-keyboard-20376} to the
+payload should send out: @footnote{The first line
+containing starting with @code{Message ID} is an
+example, it should be whatever is appropriate for
+your client.}
 
 @example
 Modify ID: 4\n
@@ -1113,8 +1068,8 @@ kernel\n
 on-screen-keyboard-20376\n
 @end example
 
-If you however decide not to modify
-the message send out
+If you however decide not to modify the message send
+out
 
 @example
 Modify ID: 4\n
@@ -1125,12 +1080,10 @@ Modify: no\n
 
 @cpindex Message consumption, message passing
 @cpindex Consumption, interception, message passing
-There is also a third option:
-to consume to the message. This
-stops any further clients from
-receiving the message. This is
-done by modifying the message
-into an empty message:
+There is also a third option: to consume to the
+message. This stops any further clients from
+receiving the message. This is done by modifying
+the message into an empty message:
 
 @example
 Modify ID: 4\n
@@ -1139,34 +1092,25 @@ Modify: yes\n
 \n
 @end example
 
-You may choose to include the
-header--value pair @code{Length: 0},
-it is however redundant and
+You may choose to include the header--value pair
+@code{Length: 0}, it is however redundant and
 discouraged.
 
 @cpindex Interception priority, message passing
 @cpindex Priority, interception, message passing
-This mechanism of being able to
-modify message does not make much
-sense unless you can control in
-the order the clients receive
-messages. This is done with what
-is called priority. The higher
-priority you have, the earlier
-you will receive the message. The
-default priority is zero, and the
-priority is bound to a signed
-64-bit integer. If you want to
-be able to list yourself in
-@code{Command: keyboard-enumeration}
-message, you should sign up
-with a positive priority since
-the final recipient or requested
-the enumeration will receive it
-with priority zero. Therefore
-you should sign up for such message
-with a message like:
-@footnote{4611686018427387904 is
+This mechanism of being able to modify message does
+not make much sense unless you can control in the
+order the clients receive messages. This is done with
+what is called priority. The higher priority you
+have, the earlier you will receive the message. The
+default priority is zero, and the priority is bound
+to a signed 64-bit integer. If you want to be able to
+list yourself in @code{Command: keyboard-enumeration}
+message, you should sign up with a positive priority
+since the final recipient or requested the
+enumeration will receive it with priority zero.
+Therefore you should sign up for such message with a
+message like: @footnote{4611686018427387904 is
 halfway to the maximium value.}
 
 @example
@@ -1200,7 +1144,8 @@ the minimum value of any signed value with a fixed
 bit-size is the negative of its maximum value, that
 is, the minimum value @code{int16_t} is to be assumed
 to be @code{-INT16_MAX} (@math{-32767}) rather than
-@code{INT16_MIN} (@math{-32768} with two's complement.)
+@code{INT16_MIN} (@math{-32768} with two's
+complement.)
 
 @item
 Integers that are not especially encoded must not be
@@ -1216,35 +1161,32 @@ can be properly stored and used.
 @cpindex Integers, unsigned, restriction
 @cpindex Unsigned integer, restriction
 @cpindex Restrictions on unsigned integers
-Integer 64-bits that are not especially encoded
-must not be unsigned if the bit-size is fixed.
-This is because some programming languages
-primitive integers are limited to 64-bits and
-are signed; a large enough unsigned 64-bit
-integer would overflow.
+Integer 64-bits that are not especially encoded must
+not be unsigned if the bit-size is fixed. This is
+ because some programming languages primitive
+integers are limited to 64-bits and are signed; a
+large enough unsigned 64-bit integer would overflow.
 
 @item
 @cpindex Endianness, portability
-Native endianness when a endianness is choosen.
-Do not assume big endianness, but the same
-endianness that appear on the same machine when
-using C@.
+Native endianness when a endianness is choosen. Do
+not assume big endianness, but the same endianness
+that appear on the same machine when using C@.
 
 @item
 @cpindex UTF-8, portability
 @cpindex Strings, portibility
-All strings musts be encoded in UTF-8 without
-any NUL-character unless express permission
-is given. NUL-character may be encoded either
-using a zero byte or using Modified UTF-8, where
-it is encoded using two bytes. Which is used is
-selected in the protocol, however headers and
-their values must not include NUL-characters.
-No character may be encoded with more bytes than
-necessary. Encoding a character in extra long
-form is a security issue, and is prune to bugs,
-and is hence disallowed by newer specifications
-of UTF-8.
+All strings musts be encoded in UTF-8 without any
+NUL-character unless express permission is given.
+NUL-character may be encoded either using a zero byte
+or using Modified UTF-8, where it is encoded using
+two bytes. Which is used is selected in the protocol,
+however headers and their values must not include
+NUL-characters. No character may be encoded with more
+bytes than necessary. Encoding a character in extra
+long form is a security issue, and is prune to bugs,
+and is hence disallowed by newer specifications of
+UTF-8.
 
 @item
 @cpindex New line, portability
@@ -1279,11 +1221,11 @@ any other character, or multiple LF:s.
 @cpindex Respawning servers, automatic
 @cpindex Crash resilience
 @command{mds-respawn} is a utility intended to be used
-in @file{$@{XDG_CONFIG_HOME@}/mdsinitrc}. It will spawn
-a selected set of servers. If a server it spawns exits
-with a bad status, @command{mds-respawn} will respawn it.
-@command{mds-respawn} supports two options in the command
-line:
+in @file{$@{XDG_CONFIG_HOME@}/mdsinitrc}. It will
+spawn a selected set of servers. If a server it
+spawns exits with a bad status, @command{mds-respawn}
+will respawn it. @command{mds-respawn} supports two
+options in the command line:
 
 @table @option
 @item --alarm=SECONDS
@@ -1318,17 +1260,17 @@ mds-respawn --interval=5       \
 @opindex @option{--initial-spawn}
 @opindex @option{--respawn}
 will spawn and supervise the servers @command{mds-foo}
-and @command{mds-bar}. Both spawned with the
-argument @option{--initial-spawn}. When a server is
-respawed by @command{mds-respawn}, @option{--initial-spawn}
-in its argument list will be replaced by
+and @command{mds-bar}. Both spawned with the argument
+@option{--initial-spawn}. When a server is respawed
+by @command{mds-respawn}, @option{--initial-spawn} in
+its argument list will be replaced by
 @option{--respawn} to let the server know it is being
 respawned.
 
 @sgindex @code{SIGTERM}
 A server is considered to exit with a failure status
-unless it exits with the return value 0 or is terminated
-by the signal @code{SIGTERM}@.
+unless it exits with the return value 0 or is
+terminated by the signal @code{SIGTERM}@.
 
 
 
@@ -1342,16 +1284,17 @@ by the signal @code{SIGTERM}@.
 @cpindex Registry of protocols
 @opindex @option{--list}
 @opindex @option{--wait}
-@command{mds-reg} is a utility that can be used to list
-available protocols provided by running servers. It can
-also wait for a set of protocols to become available. To
-list all available protocols run @command{mds-reg --list}.
-And to wait for the protocol @code{foo} run
-@command{mds-reg --wait=foo}. To also wait for the protocol
-@code{bar} run @command{mds-reg --wait=foo,bar} or
-@command{mds-reg --wait=foo --wait=bar}. Both of these
-styles can be mixed if you want to wait for even more
-protocols.
+@command{mds-reg} is a utility that can be used to
+list available protocols provided by running servers.
+It can also wait for a set of protocols to become
+available. To list all available protocols run
+@command{mds-reg --list}. And to wait for the
+protocol @code{foo} run @command{mds-reg --wait=foo}.
+To also wait for the protocol @code{bar} run
+@command{mds-reg --wait=foo,bar} or
+@command{mds-reg --wait=foo --wait=bar}. Both of
+thesestyles can be mixed if you want to wait for
+even more protocols.
 
 
 
@@ -1361,8 +1304,9 @@ protocols.
 @pgindex @command{mds-clip}
 @cpindex Clipboard
 @command{mds-clip} is a utility that can be used to
-review the clipboards on the display and manipulate them.
-@command{mds-clip} recognises the following options:
+review the clipboards on the display and manipulate
+them. @command{mds-clip} recognises the following
+options:
 
 @table @option
 @item --push
@@ -1426,9 +1370,10 @@ Can be used with @option{--stdin} or @option{--list}.
 If used with @option{--stdin}, an line containing
 only @var{DELIMITER} will delimit two values that
 should be placed in the clipboard. If used with
-@option{--list}, a line containing only @var{DELIMITER}
-will delimit two values in the output. The default
-delimiter for @option{--list} is an empty line.
+@option{--list}, a line containing only
+@var{DELIMITER} will delimit two values in the
+output. The default delimiter for @option{--list}
+is an empty line.
 
 @item -1
 @opindex @option{-1}
@@ -1464,34 +1409,34 @@ following options:
 @table @option
 @item --monitor
 @opindex @option{--monitor}
-Take screenshot of the monitor. The rat will
-be used to select monitor.
+Take screenshot of the monitor. The rat will be used
+to select monitor.
 
 @item --monitor=WINDOW_ID
 @opindex @option{--monitor}
 Take screenshot of the monitor whose root window's
-window ID is @var{WINDOW_ID} or has another window
-in it whose window ID is @var{WINDOW_ID}@.
+window ID is @var{WINDOW_ID} or has another window in
+it whose window ID is @var{WINDOW_ID}@.
 
 @item --embed
 @opindex @option{--embed}
-Take a screenshot of an embedded window.
-The rat will be used to select window.
+Take a screenshot of an embedded window. The rat will
+be used to select window.
 
 @item --embed=WINDOW_ID
 @opindex @option{--monitor}
-Take a screenshot of an embedded window whose
-window ID is @var{WINDOW_ID}@.
+Take a screenshot of an embedded window whose window
+ID is @var{WINDOW_ID}@.
 
 @item --window
 @opindex @option{--window}
-Take a screenshot a window.
-The rat will be used to select window.
+Take a screenshot a window. The rat will be used to
+select window.
 
 @item --window=WINDOW_ID
 @opindex @option{--window}
-Take a screenshot of a window whose
-window ID is @var{WINDOW_ID}@.
+Take a screenshot of a window whose window ID is
+@var{WINDOW_ID}@.
 
 @item --decoration
 @opindex @option{--decoration}
@@ -1529,8 +1474,8 @@ specifies the pathname of the saved file.
 @opindex @option{--monitor}
 @opindex @option{--embed}
 If neither @option{--monitor}, @option{--embed} or
-@option{--window} is used, a screenshot will be
-taked of the display. That is, all monitors.
+@option{--window} is used, a screenshot will be taked
+of the display. That is, all monitors.
 
 @opindex @option{--gamma}
 @opindex @option{--low-gamma}
@@ -1558,33 +1503,30 @@ following options:
 @table @option
 @item --embed
 @opindex @option{--embed}
-Kill an embedded window.
-The rat will be used to select window.
+Kill an embedded window. The rat will be used to
+select window.
 
 @item --embed=WINDOW_ID
 @opindex @option{--embed}
-Kill an embedded window whose
-window ID is @var{WINDOW_ID}@.
+Kill an embedded window whose window ID is
+@var{WINDOW_ID}@.
 
 @item --window
 @opindex @option{--window}
-Kill a window.
-The rat will be used to select window.
+Kill a window. The rat will be used to select window.
 
 @item --window=WINDOW_ID
 @opindex @option{--window}
-Kill a window whose
-window ID is @var{WINDOW_ID}@.
+Kill a window whose window ID is @var{WINDOW_ID}@.
 
 @item --signal=SIGNAL
 @opindex @option{--signal}
-Send the signal @var{SIGNAL} to the
-process owning the selected window.
+Send the signal @var{SIGNAL} to the process owning
+the selected window.
 
 @item --no-signal
 @opindex @option{--no-signal}
-Do not send a signal; only identify the
-window.
+Do not send a signal; only identify the window.
 
 @item --keep-cursor
 @opindex @option{--keep-cursor}
@@ -1605,17 +1547,18 @@ Print the ID of the selected window.
 @cpindex Virtual terminal, switching
 @cpindex Switching virtual terminal
 @command{mds-chvt} is a utility similar to the command
-@command{chvt} from the @command{kbd} project. However,
-@command{mds-chvt} has setuid and therefore does not
-require root permissions, but it will only request a
-virtual terminal switch if the display server's virtual
-terminal is in the foreground. @command{mds-chvt}
-recognises the following options:
+@command{chvt} from the @command{kbd} project.
+However, @command{mds-chvt} has setuid and therefore
+does not require root permissions, but it will only
+request a virtual terminal switch if the display
+server's virtual terminal is in the foreground.
+@command{mds-chvt} recognises the following options:
 
 @table @option
 @item --switch=VT
 @opindex @option{--switch}
-Switch to the virtual terminal with the index @var{VT}@.
+Switch to the virtual terminal with the index
+@var{VT}@.
 @end table
 
 
@@ -1643,10 +1586,10 @@ TODO how to use mds-kbdc
 @pgindex @file{mdsinitrc}
 Servers let you use the option @option{--on-init-fork}
 to put the process in the background when it has been
-initialised. This can used to spawn that depend on each
-other in linear order. For example, if @command{mds-bar}
-requires that @command{mds-foo} is initialised before it
-can be initialised, you can in
+initialised. This can used to spawn that depend on
+each other in linear order. For example, if
+@command{mds-bar} requires that @command{mds-foo} is
+initialised before it can be initialised, you can in
 @file{$@{XDG_CONFIG_HOME@}/mdsinitrc} write:
 
 @example
@@ -1661,15 +1604,16 @@ mds-bar &
 @pgindex @command{mds-respawn}
 @pgindex @command{cmdipc}
 @pgindex @command{ipcmd}
-This will start @command{mds-bar} when @command{mds-foo}
-has been initialised. However if one of them crashes,
-that server will not respawn; to fix this @command{mds-respawn}
-can be used, but use of @command{mds-respawn} hinders
-the use of @option{--on-init-fork}. Instead you can use
-@option{--on-init-sh} and global semaphores. The packages,
-and commands, @command{cmdipc} and @command{ipcmd} can be
-used for this purpose. We will use @command{cmdipc} in an
-example:
+This will start @command{mds-bar} when
+@command{mds-foo} has been initialised. However if
+one of them crashes, that server will not respawn; to
+fix this @command{mds-respawn} can be used, but use
+of @command{mds-respawn} hinders the use of
+@option{--on-init-fork}. Instead you can use
+@option{--on-init-sh} and global semaphores. The
+packages, and commands, @command{cmdipc} and
+@command{ipcmd} can be used for this purpose. We will
+use @command{cmdipc} in an example:
 
 @ifset AFOURPAPER
 @example
@@ -1717,20 +1661,21 @@ mds-respawn @{ mds-bar @} &  # Spawn `mds-bar`.
 @end ifclear
 
 @pgindex @command{mds-reg}
-This is however seldom necessary as @command{mds-reg} can
-often be used instead, with more abstraction as you would
-only need to specify what servers need to wait for, not
-what they provide.
+This is however seldom necessary as @command{mds-reg}
+can often be used instead, with more abstraction as
+you would only need to specify what servers need to
+wait for, not what they provide.
 
 @pgindex @command{setpgrp}
 @cpindex Display server process group
 @cpindex Process group, display server
-Another useful command (and package) is @command{setpgrp}.
-@command{mds} puts itself an all its children in a new
-process group. However you may want to put processes that
-are not @command{mds} servers or @command{mds} utilities
-in a separate process group. @command{setpgrp} can be used
-to starta process in a new process group.
+Another useful command (and package) is
+@command{setpgrp}. @command{mds} puts itself an all
+its children in a new process group. However you may
+want to put processes that are not @command{mds}
+servers or @command{mds} utilities in a separate
+process group. @command{setpgrp} can be used to start
+a process in a new process group.
 
 
 
@@ -1742,12 +1687,13 @@ to starta process in a new process group.
 @cpindex Kernel
 @cpindex Display server kernel
 @cpindex Master server
-An @command{mds} display server instance is comprised of
-multiple small servers that each implements a small part
-of the display server's functionallity. This chapter will
-include all servers but the master server, @command{mds-server}
-and the kernel, @command{mds}, the latter of which is not
-actually a server.
+An @command{mds} display server instance is comprised
+of multiple small servers that each implements a
+small part of the display server's functionallity.
+This chapter will include all servers but the master
+server, @command{mds-server} and the kernel,
+@command{mds}, the latter of which is not actually a
+server.
 
 @menu
 * mds-echo::                        The @command{mds-echo} server.
@@ -1819,10 +1765,11 @@ actually a server.
 @cpindex Debugging
 @cpindex Heartbeat
 @cpindex Network heartbeat
-@command{mds-echo} is a server that echos message that
-contain the header--value pair @command{Command: echo}.
-This server can be used for debugging and testing as
-well as to enable network heartbeats.
+@command{mds-echo} is a server that echos message
+that contain the header--value pair
+@command{Command: echo}.
+This server can be used for debugging and testing
+as well as to enable network heartbeats.
 
 
 
@@ -1834,10 +1781,11 @@ well as to enable network heartbeats.
 @cpindex Protocols, listing
 @cpindex Protocol registry
 @cpindex Registry of protocols
-@command{mds-registry} is a server that keeps a registry
-of all protocols that are supported they the sum of all
-active servers. It can also be used by other servers to
-wait until a protocol has become available.
+@command{mds-registry} is a server that keeps a
+registry of all protocols that are supported they the
+sum of all active servers. It can also be used by
+other servers to wait until a protocol has become
+available.
 
 
 
@@ -1892,8 +1840,8 @@ package.
 @cpindex Clipboard
 @command{mds} has three clipboards, one for copied
 text, one for selected text, and one for non-textual
-data. Each of these clipboards are stacks, just
-like in GNU Emacs. @command{mds-clipboard} implements
+data. Each of these clipboards are stacks, just like
+in GNU Emacs. @command{mds-clipboard} implements
 these clipboards and automatic removal of outdated
 clips. Clips can be configured to expire based on
 time or when its originator closes.
@@ -1920,13 +1868,14 @@ drag-and-drop support.
 @cpindex Keycodes
 @cpindex Keycodes, remapping
 @cpindex Keyboard, remapping
-@command{mds-kkbd} implements access to the kernel-based
-keyboard. It does not however implement delay and rate
-configurations for the kernel-based keyboard as that
-requires root privileges. The kernel-based keyboard is
-a keyboard that can be accessed by reconfiguring
-stdin in a TTY using @code{ioctl} and then read from
-stdin. @command{mds-kkbd} does not implement any keyboard
+@command{mds-kkbd} implements access to the
+kernel-based keyboard. It does not however implement
+delay and rate configurations for the kernel-based
+keyboard as that requires root privileges. The
+kernel-based keyboard is a keyboard that can be
+accessed by reconfiguring stdin in a TTY using
+@code{ioctl} and then read from stdin.
+@command{mds-kkbd} does not implement any keyboard
 layout, rather it broadcasts scancodes and keycodes.
 However it can remap keycodes, but not scancodes.