1.1 --- a/ch03.roff	Sun Apr 22 17:16:30 2012 +0200
     1.2 +++ b/ch03.roff	Tue Apr 24 16:52:25 2012 +0200
     1.3 @@ -52,7 +52,7 @@
     1.4  I did drop any support for the MMDF maildrop format. This type of format
     1.5  is conceptionally similar to the mbox format, but uses four bytes with
     1.6  value 1 (\fL^A^A^A^A\fP) as message delimiter,
     1.7 -instead of the string ``\fLFrom\0\fP''.
     1.8 +instead of the string ``\fLFrom\ \fP''.
     1.9  Due to the similarity and mbox being the de-facto standard maildrop
    1.10  format on Unix, but also due to the larger influence of Sendmail than MMDF,
    1.11  the MMDF maildrop format had vanished.
    1.12 @@ -67,7 +67,9 @@
    1.13  The direct MMDF code had been removed, but as now only one packed mailbox
    1.14  format is left, code structure simplifications are likely possible.
    1.15  The reason why they are still outstanding is the heavily optimized code
    1.16 -of \fLm_getfld()\fP. Changes beyond a small local scope \(en
    1.17 +of
    1.18 +.Fu m_getfld() .
    1.19 +Changes beyond a small local scope \(en
    1.20  which restructuring in its core is \(en cause a high risk of damaging
    1.21  the intricate workings of the optimized code. This problem is know
    1.22  to the developers of nmh, too. They also avoid touching this minefield
    1.23 @@ -93,8 +95,12 @@
    1.24  actually being able to work on it, but I fear my chances are null.
    1.25  .P
    1.26  The check only prevented a pager to be placed between the outputting
    1.27 -program (\fLmhl\fP) and the terminal. This could have been ensured with
    1.28 -the \fL-nomoreproc\fP at the command line statically, too.
    1.29 +program (\c
    1.30 +.Pn mhl )
    1.31 +and the terminal. This could have been ensured with
    1.32 +the
    1.33 +.Sw \-nomoreproc
    1.34 +at the command line statically, too.
    1.35  
    1.36  .U2 "Removed support for header fields
    1.37  .P
    1.38 @@ -120,7 +126,9 @@
    1.39  .H1 "Draft and Trash Folders
    1.40  .U2 "Draft Folder
    1.41  .P
    1.42 -Historically, MH provided exactly one draft message, named `\fLdraft\fP' and
    1.43 +Historically, MH provided exactly one draft message, named
    1.44 +.Fn draft
    1.45 +and
    1.46  being located in the MH directory. When starting to compose another message
    1.47  before the former one was sent, the user had been questioned wether to use,
    1.48  refile or replace the old draft. Working on multiple drafts at the same time
    1.49 @@ -133,7 +141,9 @@
    1.50  draft folder facility exists. It had been introduced already in July 1984
    1.51  by Marshall T. Rose. The facility was deactivated by default.
    1.52  Even in nmh, the draft folder facility remained deactivated by default.
    1.53 -At least, Richard Coleman added the man page \fImh-draft(5)\fP to document
    1.54 +At least, Richard Coleman added the man page
    1.55 +.Mp mh-draft(5)
    1.56 +to document
    1.57  the feature well.
    1.58  .P
    1.59  The only advantage of not using the draft folder facility is the static
    1.60 @@ -145,28 +155,45 @@
    1.61  On the other hand, a draft folder is the much more natural concept than
    1.62  a draft message. MH's mail storage consists of folders and messages,
    1.63  the messages named with ascending numbers. A draft message breaks with this
    1.64 -concept by introducing a message in a file named ``\fLdraft\fP''. This draft
    1.65 +concept by introducing a message in a file named
    1.66 +.Fn draft .
    1.67 +This draft
    1.68  message is special. It can not be simply listed with the available tools,
    1.69  but instead requires special switches. I.e. corner-cases were
    1.70  introduced. A draft folder, in contrast, does not introduce such
    1.71  corner-cases. The available tools can operate on the messages within that
    1.72  folder like on any messages within any mail folders. The only difference
    1.73 -is the fact that the default folder for \fLsend\fP is the draft folder,
    1.74 +is the fact that the default folder for
    1.75 +.Pn send
    1.76 +is the draft folder,
    1.77  instead of the current folder, like for all other tools.
    1.78  .P
    1.79  The trivial part of the change was activating the draft folder facility
    1.80  by default and setting a default name for this folder. Obviously, I chose
    1.81 -the name ``\fL+drafts\fP''. This made the \fL\-draftfolder\fP and
    1.82 -\fL\-draftmessage\fP switches useless, and I could remove them.
    1.83 +the name
    1.84 +.Fn +drafts .
    1.85 +This made the
    1.86 +.Sw \-draftfolder
    1.87 +and
    1.88 +.Sw \-draftmessage
    1.89 +switches useless, and I could remove them.
    1.90  The more difficult but also the part that showed the real improvement,
    1.91 -was updating the tools to the new concept. \fL\-draft\fP switches could
    1.92 +was updating the tools to the new concept.
    1.93 +.Sw \-draft
    1.94 +switches could
    1.95  be dropped, as operating on a draft message became indistinguishable to
    1.96 -operating on any other message for the tools. \fLcomp\fP still has its
    1.97 -\fL\-use\fP switch for switching between its two modes: (1) Compose a new
    1.98 +operating on any other message for the tools.
    1.99 +.Pn comp
   1.100 +still has its
   1.101 +.Sw \-use
   1.102 +switch for switching between its two modes: (1) Compose a new
   1.103  draft, possibly by taking some existing message as a form. (2) Modify
   1.104 -an existing draft. In either case, the behavior of \fLcomp\fP is
   1.105 +an existing draft. In either case, the behavior of
   1.106 +.Pn comp is
   1.107  deterministic. There is no more need to query the user. I consider this
   1.108 -a major improvement. By making \fLsend\fP simply operate on the current
   1.109 +a major improvement. By making
   1.110 +.Pn send
   1.111 +simply operate on the current
   1.112  message in the draft folder by default, with message and folder both
   1.113  overridable by specifying them on the command line, it is now possible
   1.114  to send a draft anywhere within the storage by simply specifying its folder
   1.115 @@ -179,7 +206,10 @@
   1.116  .P
   1.117  Similar to the situation for drafts is the situation for removed messages.
   1.118  Historically, a message was deleted by renaming. A specific
   1.119 -\fIbackup prefix\fP, often comma (\fL,\fP) or hash (\fL#\fP),
   1.120 +\fIbackup prefix\fP, often comma (\c
   1.121 +.Fn , )
   1.122 +or hash (\c
   1.123 +.Fn # ),
   1.124  being prepended to the file name. Thus, MH wouldn't recognize the file
   1.125  as a message anymore, as only files whose name consists of digits only
   1.126  are treated as messages. The removed messages remained as files in the
   1.127 @@ -191,9 +221,14 @@
   1.128  in a cron job. Within the grace time interval
   1.129  the original message could be restored by stripping the
   1.130  the backup prefix from the file name. If however, the last message of
   1.131 -a folder is been removed \(en say message `\fL6\fP' becomes file
   1.132 -`\fL,6\fP' \(en and a new message enters the same folder, thus the same
   1.133 -numbered being given again \(en in our case `\fL6\fP' \(en, if that one
   1.134 +a folder is been removed \(en say message
   1.135 +.Fn 6
   1.136 +becomes file
   1.137 +.Fn ,6
   1.138 +\(en and a new message enters the same folder, thus the same
   1.139 +numbered being given again \(en in our case
   1.140 +.Fn 6
   1.141 +\(en, if that one
   1.142  is removed too, then the backup of the former message gets overwritten.
   1.143  Thus, the ability to restore removed messages does not only depend on
   1.144  the ``sweeping cron job'' but also on the removing of further messages.
   1.145 @@ -202,40 +237,62 @@
   1.146  Further more, the backup files are scattered within the whole mail
   1.147  storage, instead of being collected at one place.
   1.148  .P
   1.149 -To improve the situation, the profile entry \fIrmmproc\fP
   1.150 -(previously named \fIDelete-Prog\fP) was introduced, very early.
   1.151 +To improve the situation, the profile entry
   1.152 +.Pe rmmproc
   1.153 +(previously named
   1.154 +.Pe Delete-Prog )
   1.155 +was introduced, very early.
   1.156  It could be set to any command, which would care for the mail removal
   1.157  instead of taking the default action, described above.
   1.158  Refiling the to-be-removed files to some wastebin folder was a common
   1.159 -example. Nmh's man page for \fLrmm(1)\fP proposes `\fLrefile +d\fP'
   1.160 -to move messages to the wastebin and `\fLrm `mhpath +d all`\fP'
   1.161 +example. Nmh's man page
   1.162 +.Mp rmm(1)
   1.163 +proposes
   1.164 +.Cl "refile +d
   1.165 +to move messages to the wastebin and
   1.166 +.Cl "rm `mhpath +d all`
   1.167  the empty the wastebin.
   1.168  Managing the message removal this way is a sane approach. It keeps
   1.169  the removed messages in one place, makes it easy to remove the backup
   1.170  files, and, most important, enables the user to use the tools of MH
   1.171 -itself to operate on the removed messages. One can \fLscan\fP them,
   1.172 -\fLshow\fP them, and restore them with \fLrefile(1)\fP. There's no more
   1.173 -need to use \fLmhpath\fP to switch over from MH tools to Unix tools
   1.174 -\(en MH can do it all itself.
   1.175 +itself to operate on the removed messages. One can
   1.176 +.Pn scan
   1.177 +them,
   1.178 +.Pn show
   1.179 +them, and restore them with
   1.180 +.Pn refile .
   1.181 +There's no more
   1.182 +need to use
   1.183 +.Pn mhpath
   1.184 +to switch over from MH tools to Unix tools \(en MH can do it all itself.
   1.185  .P
   1.186 -This apporach is matches perfect with the concepts of MH, thus making
   1.187 +This apporach matches perfect with the concepts of MH, thus making
   1.188  it powerful. Hence, I made it the default. And even more, I also
   1.189  removed the old backup prefix approach, as it is clearly less powerful.
   1.190  Keeping unused alternative in the code is a bad choice as they likely
   1.191  gather bugs, by not being constantly tested. Also, the increased code
   1.192  size and more conditions crease the maintenance costs. By strictly
   1.193  converting to the trash folder approach, I simplified the code base.
   1.194 -\fLrmm(1)\fP calls \fLrefile(1)\fP internally to move the to-be-removed
   1.195 -message to the trash folder (`\fL+trash\fP' by default). Messages
   1.196 +.Pn rmm
   1.197 +calls
   1.198 +.Pn refile
   1.199 +internally to move the to-be-removed
   1.200 +message to the trash folder (\c
   1.201 +.Fn +trash
   1.202 +by default). Messages
   1.203  there can be operated on like on any other message in the storage.
   1.204 -The sweep clean, one can use `\fLrmm \-unlink +trash a\fP', where
   1.205 -the `\fL\-unlink\fP' switch causes the files to be truly unliked instead
   1.206 +The sweep clean, one can use
   1.207 +.Cl "rmm \-unlink +trash a" ,
   1.208 +where the
   1.209 +.Sw \-unlink
   1.210 +switch causes the files to be truly unliked instead
   1.211  of moved to the trash folder.
   1.212  
   1.213  
   1.214  .H1 "MH Directory Split
   1.215  .P
   1.216 -
   1.217 +Historically, a personal MH setup had consisted of two things:
   1.218 +the 
   1.219  
   1.220  
   1.221  .H1 "Path Notations