1.1 --- a/ch03.roff	Wed Jun 20 19:39:29 2012 +0200
     1.2 +++ b/ch03.roff	Thu Jun 21 00:01:13 2012 +0200
     1.3 @@ -1,7 +1,8 @@
     1.4  .H0 "Discussion
     1.5  .P
     1.6  This main chapter discusses the practical work done in the mmh project.
     1.7 -It is structured along the goals to achieve. The concrete work done
     1.8 +It is structured along the goals to achieve.
     1.9 +The concrete work done
    1.10  is described in the examples of how the general goals were achieved.
    1.11  The discussion compares the current version of mmh with the state of
    1.12  nmh just before the mmh project started, i.e. Fall 2011.
    1.13 @@ -1639,159 +1640,207 @@
    1.14  .H2 "Code Relicts
    1.15  .P
    1.16  My position to drop obsolete functionality of mmh to remove old code
    1.17 -is much more revolutional than the nmh community likes it.
    1.18 -Without the need to justify my decisions, I was able to quickly
    1.19 -remove functionality I considered ancient.
    1.20 -The need to discuss my decisions with
    1.21 -peers likely would have slowed this process down.
    1.22 -Of course, I researched if a particular feature really should be dropped.
    1.23 -Having not had any
    1.24 -contact to this feature within my computer life was a first indicator to
    1.25 -drop it, but I also asked others and searched the literature for modern
    1.26 -usage of the feature.
    1.27 -If it appeared to be truly ancient, I dropped it.
    1.28 -The reason for dropping is always part of the commit message in the
    1.29 +is much more revolutional than the nmh community likes to have it.
    1.30 +Working on an experimental version, I was able to quickly drop
    1.31 +functionality I considered ancient.
    1.32 +The need for consensus with peers would have slowed this process down.
    1.33 +Without the need to justify my decisions, I was able to rush forward.
    1.34 +In Dezember 2011, Paul Vixie motivated the nmh developers to just
    1.35 +do the work:
    1.36 +.[
    1.37 +paul vixie edginess nmh-workers
    1.38 +.]
    1.39 +.QS
    1.40 +let's stop walking on egg shells with this code base. there's no need to
    1.41 +discuss whether to keep using vfork, just note in [sic!] passing, [...]
    1.42 +we don't need a separate branch for removing vmh
    1.43 +or ridding ourselves of #ifdef's or removing posix replacement functions
    1.44 +or depending on pure ansi/posix "libc".
    1.45 +.QP
    1.46 +these things should each be a day or two of work and the "main branch"
    1.47 +should just be modern. [...]
    1.48 +let's push forward, aggressively.
    1.49 +.QE
    1.50 +.LP
    1.51 +I did so already in the months before.
    1.52 +I pushed forward.
    1.53 +I simply dropped the cruft.
    1.54 +.P
    1.55 +The decision to drop a feature was based on literature research and
    1.56 +careful thinking, but whether having had contact to this particular
    1.57 +feature within my own computer life served as a rule of thumb.
    1.58 +My reasons are always made clean in the commit message for the
    1.59  version control system.
    1.60 -Thus, it is easy for others to check their
    1.61 -view on the topic with mine and possibly to argue for reinclusion.
    1.62 +Hence, others can comprehend my view and argue for undoing the change
    1.63 +if I have missed an important aspect.
    1.64  
    1.65  
    1.66 -.U3 "MMDF maildrop support
    1.67 +.U3 "Forking
    1.68  .P
    1.69 -I did drop any support for the MMDF maildrop format.
    1.70 -This type of format
    1.71 -is conceptionally similar to the mbox format, but uses four bytes with
    1.72 -value 1 (\fL^A^A^A^A\fP) as message delimiter,
    1.73 -instead of the string ``\fLFrom\ \fP''.
    1.74 -Due to the similarity and mbox being the de-facto standard maildrop
    1.75 -format on Unix, but also due to the larger influence of Sendmail than MMDF,
    1.76 -the MMDF maildrop format had vanished.
    1.77 +In being a tool chest, MH creates many processes.
    1.78 +In earlier times
    1.79 +.Fu fork()
    1.80 +had been an expensive system call, because the process's image needed
    1.81 +to be duplicated completely at once.
    1.82 +This was especially painfull in the common case when the image gets
    1.83 +replaced by a call to
    1.84 +.Fu exec()
    1.85 +right after having forked the child process.
    1.86 +The
    1.87 +.Fu vfork()
    1.88 +system call was invented to speed up this particular case.
    1.89 +It completely omits the duplication of the image.
    1.90 +On old systems this resulted in significant speed ups.
    1.91 +Therefore MH used
    1.92 +.Fu vfork()
    1.93 +whenever possible.
    1.94  .P
    1.95 -The simplifications within the code were only moderate.
    1.96 -Switches could be removed from tools like
    1.97 -.L packf ,
    1.98 -which generate packed mailboxes.
    1.99 -Only one packed mailbox format remained: mbox.
   1.100 -The most important changes affect the equally named mail parsing routine in
   1.101 -.L sbr/m_getfld.c .
   1.102 -The direct MMDF code had been removed, but as now only one packed mailbox
   1.103 -format is left, code structure simplifications are likely possible.
   1.104 -The reason why they are still outstanding is the heavily optimized code
   1.105 -of
   1.106 -.Fu m_getfld() .
   1.107 -Changes beyond a small local scope \(en
   1.108 -which restructuring in its core is \(en cause a high risk of damaging
   1.109 -the intricate workings of the optimized code.
   1.110 -This problem is know to the developers of nmh, too.
   1.111 -They also avoid touching this minefield if possible.
   1.112 +Modern memory management units support copy-on-write semantics, which make
   1.113 +.Fu fork()
   1.114 +almost as fast as
   1.115 +.Fu vfork() .
   1.116 +The man page of
   1.117 +.Mp vfork (2)
   1.118 +in FreeBSD 8.0 states:
   1.119 +.QS
   1.120 +This system call will be eliminated when proper system sharing mechanisms
   1.121 +are implemented. Users should not depend on the memory sharing semantics
   1.122 +of vfork() as it will, in that case, be made synonymous to fork(2).
   1.123 +.QE
   1.124 +.LP
   1.125 +Vixie supports the removal with the note that ``the last
   1.126 +system on which fork was so slow that an mh user would notice it, was
   1.127 +Eunice. that was 1987''.
   1.128 +.[
   1.129 +nmh-workers vixie edginess
   1.130 +.]
   1.131 +I replaced all calls to
   1.132 +.Fu vfork()
   1.133 +with calls to
   1.134 +.Fu fork() .
   1.135 +.P
   1.136 +Related to the costs of
   1.137 +.Fu fork()
   1.138 +is the probability of its success.
   1.139 +In the Eighties on heavy loaded systems, calls to
   1.140 +.Fu fork()
   1.141 +were prone to failure.
   1.142 +Hence, many of the
   1.143 +.Fu fork()
   1.144 +calls in the code were wrapped into loops to retry the
   1.145 +.Fu fork()
   1.146 +several times, for higher changes to succeed, eventually.
   1.147 +On modern systems, failing calls to
   1.148 +.Fu fork()
   1.149 +are unusual.
   1.150 +Hence, in the rare case when
   1.151 +.Fu fork()
   1.152 +fails, mmh programs simply abort.
   1.153  
   1.154 -.U3 "UUCP Bang Paths
   1.155 -.P
   1.156 -More questionably than the former topic is the removal of support for the
   1.157 -UUCP bang path address style.
   1.158 -However, the user may translate the bang
   1.159 -paths on retrieval to Internet addresses and the other way on posting
   1.160 -messages.
   1.161 -The former can be done my an MDA like procmail; the latter
   1.162 -by a sendmail wrapper.
   1.163 -This would ensure that any address handling would work as expected.
   1.164 -However, it might just work well without any
   1.165 -such modifications, as mmh does not touch addresses much, in general.
   1.166 -But I can't ensure as I have never used an environment with bang paths.
   1.167 -Also, the behavior might break at any point in further development.
   1.168  
   1.169 -.U3 "Hardcopy terminal support
   1.170 -.P
   1.171 -More of a funny anecdote is the remaining of a check for printing to a
   1.172 -hardcopy terminal until Spring 2012, when I finally removed it.
   1.173 -I surely would be very happy to see such a terminal in action, maybe
   1.174 -actually being able to work on it, but I fear my chances are null.
   1.175 -.P
   1.176 -The check only prevented a pager to be placed between the outputting
   1.177 -program (\c
   1.178 -.Pn mhl )
   1.179 -and the terminal.
   1.180 -This could have been ensured with the
   1.181 -.Sw -nomoreproc
   1.182 -at the command line statically, too.
   1.183 -
   1.184 -.U3 "Removed support for header fields
   1.185 -.P
   1.186 +.U3 "Obsolete Header Fields
   1.187 +.BU
   1.188  The
   1.189  .Hd Encrypted
   1.190 -header field had been introduced by RFC\^822, but already
   1.191 -marked legacy in RFC 2822.
   1.192 -It was superseded by FIXME.
   1.193 -Mmh does no more support this header field.
   1.194 -.P
   1.195 +header field was introduced by RFC\|822,
   1.196 +but already marked legacy in RFC\|2822.
   1.197 +OpenPGP provides the basis for standardized exchange of encrypted
   1.198 +messages [RFC\|4880, RFC\|3156].
   1.199 +The support for
   1.200 +.Hd Encrypted
   1.201 +header fields is removed in mmh.
   1.202 +.BU
   1.203  Native support for
   1.204  .Hd Face
   1.205 -header fields had been removed, as well.
   1.206 -The feature is similar to the
   1.207 +header fields has been removed, as well.
   1.208 +This feature is similar to the
   1.209  .Hd X-Face
   1.210  header field in its intent,
   1.211  but takes a different approach to store the image.
   1.212  Instead of encoding the image data directly into the header field,
   1.213  the it contains the hostname and UDP port where the image
   1.214  date could be retrieved.
   1.215 -Neither
   1.216 +There is even a third system, invented in 2005.
   1.217 +Although it re-uses the
   1.218 +.Hd Face
   1.219 +header field, it is the successor of
   1.220  .Hd X-Face
   1.221 -nor the here described
   1.222 -.Hd Face
   1.223 -system
   1.224 -\**
   1.225 -.FS
   1.226 -There is also a newer but different system, invented 2005,
   1.227 -using
   1.228 -.Hd Face
   1.229 -headers.
   1.230 -It is the successor of
   1.231 -.Hd X-Face
   1.232 -providing colored PNG images.
   1.233 -.FE
   1.234 -became well used in the large scale.
   1.235 -It's still possible to use a Face systems,
   1.236 -although mmh does not provide support for any of the different systems
   1.237 -anymore. It's fairly easy to write a small shell script to 
   1.238 -extract the embedded or fetch the external Face data and display the image.
   1.239 -Own
   1.240 -.Hd Face
   1.241 -header field can be added into the draft template files.
   1.242 +with support for colored PNG images.
   1.243 +None of the Face systems described here is popular today.
   1.244 +Hence, mmh has no direct support for them.
   1.245 +.BU
   1.246 +The
   1.247 +.Hd Content-MD5
   1.248 +header field was introduced by RFC\|1864.
   1.249 +It provides detection of data corruption during the transfer.
   1.250 +But it can not ensure verbatim end-to-end delivery of the contents
   1.251 +[RFC\|1864].
   1.252 +The proper approach to verify content integrity in an
   1.253 +end-to-end relationship is the use of digital cryptography.
   1.254 +.\" XXX (RFCs FIXME).
   1.255 +On the other hand, transfer protocols should detect corruption during
   1.256 +each transmission. The TCP includes a checksum field therefore.
   1.257 +These two approaches in combinations render the
   1.258 +.Hd Content-MD5
   1.259 +header field superfluous.
   1.260 +The nmh-workers mailing list archive contains about 4\|200 messages,
   1.261 +ranging from 1992 until today.
   1.262 +Not a single one had a
   1.263 +.Hd Content-MD5
   1.264 +header field.
   1.265 +Neither did any of the 60\|000 messages in my personal mail storage.
   1.266 +Removing the support for this header field,
   1.267 +removed the last place where MD5 computation was needed.
   1.268 +Hence, the MD5 code could be removed as well.
   1.269 +Over 500 lines of code vanished by this one change.
   1.270 +
   1.271 +
   1.272 +.U3 "MMDF maildrop support
   1.273  .P
   1.274 -.Hd Content-MD5
   1.275 -header fields were introduced by RFC\^1864. They provide only
   1.276 -a verification of data corruption during the transfer. By no means can
   1.277 -they ensure verbatim end-to-end delivery of the contents. This is clearly
   1.278 -stated in the RFC. The proper approach to provide verificationability
   1.279 -of content in an end-to-end relationship is the use of digital cryptography
   1.280 -(RFCs FIXME). On the other hand, transfer protocols should ensure the
   1.281 -integrity of the transmission. In combinations these two approaches
   1.282 -make the
   1.283 -.Hd Content-MD5
   1.284 -header field useless. In consequence, I removed
   1.285 -the support for it. By this removal, MD5 computation is not needed
   1.286 -anywhere in mmh. Hence, over 500 lines of code were removed by this one
   1.287 -change. Even if the
   1.288 -.Hd Content-MD5
   1.289 -header field is useful sometimes,
   1.290 -I value its usefulness less than the improvement in maintainability, caused
   1.291 -by the removal.
   1.292 +This type of format is conceptionally similar to the mbox format,
   1.293 +but uses a different message delimiter (`\fL^A^A^A^A\fP' instead of
   1.294 +`\fLFrom\0\fP').
   1.295 +Mbox is the de-facto standard maildrop format on Unix,
   1.296 +whereas the MMDF maildrop format is hardly still known today.
   1.297 +I did drop MMDF maildrop format support.
   1.298 +.P
   1.299 +The simplifications within the code were only moderate.
   1.300 +Switches could be removed from
   1.301 +.L packf
   1.302 +and
   1.303 +.L rcvpack ,
   1.304 +which generate packed mailboxes.
   1.305 +Only one packed mailbox format remained: mbox.
   1.306 +The more important changes affected the equally named mail parsing
   1.307 +routine in
   1.308 +.Fn sbr/m_getfld.c .
   1.309 +The MMDF code had been removed there, but as now only one packed mailbox
   1.310 +format is left, further code structure simplifications may be possible.
   1.311 +I have not worked on them yet because
   1.312 +.Fu m_getfld()
   1.313 +is heavily optimized and thus dangerous to touch.
   1.314 +The risk of damaging the intricate workings of the optimized code is
   1.315 +too high.
   1.316 +.\" XXX: move somewhere else
   1.317 +This problem is know to the developers of nmh, too.
   1.318 +They also avoid touching this minefield if possible.
   1.319 +
   1.320  
   1.321  .U3 "Prompter's Control Keys
   1.322  .P
   1.323  The program
   1.324  .Pn prompter
   1.325 -queries the user to fill in a message form. When used by
   1.326 +queries the user to fill in a message form.
   1.327 +When used by
   1.328  .Pn comp
   1.329 -as:
   1.330 -.VS
   1.331 -comp -editor prompter
   1.332 -VE
   1.333 +as
   1.334 +.Cl "comp -editor prompter" ,
   1.335  the resulting behavior is similar to
   1.336  .Pn mailx .
   1.337  Apparently,
   1.338  .Pn prompter
   1.339 -hadn't been touched lately. Otherwise it's hardly explainable why it
   1.340 +hadn't been touched lately.
   1.341 +Otherwise it's hardly explainable why it
   1.342  still offered the switches
   1.343  .Sw -erase
   1.344  .Ar chr
   1.345 @@ -1803,50 +1852,34 @@
   1.346  Today these things work out-of-the-box, and if not, are configured
   1.347  with the standard tool
   1.348  .Pn stty .
   1.349 +The switches are removed now
   1.350 +.Ci 0bd9750710cdbab80cfb4036dd87af20afe1552f .
   1.351  
   1.352 -.U3 "Vfork and Retry Loops
   1.353 +
   1.354 +.U3 "Hardcopy terminal support
   1.355  .P
   1.356 -MH creates many processes, which is a consequence of the tool chest approach.
   1.357 -In earlier times
   1.358 -.Fu fork()
   1.359 -had been an expensive system call, as the process's whole image needed
   1.360 -to be duplicated. One common case is replacing the image with
   1.361 -.Fu exec()
   1.362 -right after having forked the child process.
   1.363 -To speed up this case, the
   1.364 -.Fu vfork()
   1.365 -system call was invented at Berkeley. It completely omits copying the
   1.366 -image. If the image gets replaced right afterwards then unnecessary
   1.367 -work is omited. On old systems this results in large speed ups.
   1.368 -MH uses
   1.369 -.Fu vfork()
   1.370 -whenever possible.
   1.371 +More of a funny anecdote is a check for printing to a
   1.372 +hardcopy terminal that remained in the code until Spring 2012,
   1.373 +when I finally removed it
   1.374 +.Ci b7764c4a6b71d37918a97594d866258f154017ca .
   1.375 +I surely would be very happy to see such a terminal in action,
   1.376 +maybe actually being able to work on it, but I fear my chances are null.
   1.377  .P
   1.378 -Memory management units that support copy-on-write semantics make
   1.379 -.Fu fork()
   1.380 -almost as fast as
   1.381 -.Fu vfork()
   1.382 -in the cases when they can be exchanged.
   1.383 -With
   1.384 -.Fu vfork()
   1.385 -being more error-prone and hardly faster, it's preferable to simply
   1.386 -use
   1.387 -.Fu fork()
   1.388 -instead.
   1.389 -.P
   1.390 -Related to the costs of
   1.391 -.Fu fork()
   1.392 -is the probability of its success.
   1.393 -Today on modern systems, the system call will succeed almost always.
   1.394 -In the Eighties on heavy loaded systems, as they were common at
   1.395 -universities, this had been different. Thus, many of the
   1.396 -.Fu fork()
   1.397 -calls were wrapped into loops to retry to fork several times in
   1.398 -short intervals, in case of previous failure.
   1.399 -In mmh, the program aborts at once if the fork failed.
   1.400 -The user can reexecute the command then. This is expected to be a
   1.401 -very rare case on modern systems, especially personal ones, which are
   1.402 -common today.
   1.403 +The check only prevented a pager to be placed between the outputting
   1.404 +program (\c
   1.405 +.Pn mhl )
   1.406 +and the terminal.
   1.407 +In nmh, this could have been ensured with the
   1.408 +.Sw -nomoreproc
   1.409 +at the command line statically, too.
   1.410 +In mmh, set the profile entry
   1.411 +.Pe Pager
   1.412 +or the environment variable
   1.413 +.Ev PAGER
   1.414 +to
   1.415 +.Pn cat .
   1.416 +
   1.417 +
   1.418  
   1.419  
   1.420  .H2 "Attachments
   1.421 @@ -2131,7 +2164,8 @@
   1.422  Luckily, Lyndon Nerenberg focused on this task at the nmh project.
   1.423  He converted large parts of the code to POSIX constructs, removing
   1.424  the conditionals compilation for now standardized features.
   1.425 -I'm thankful for this task being solved. I only pulled the changes into
   1.426 +I'm thankful for this task being solved.
   1.427 +I only pulled the changes into
   1.428  mmh.
   1.429  
   1.430  
   1.431 @@ -2146,14 +2180,18 @@
   1.432  .Fn \&.mh_profile
   1.433  and being located directly in the user's home directory.
   1.434  And the MH directory, where all his mail messages and also his personal
   1.435 -forms, scan formats, other configuration files are stored. The location
   1.436 -of this directory could be user-chosen. The default was to name it
   1.437 +forms, scan formats, other configuration files are stored.
   1.438 +The location
   1.439 +of this directory could be user-chosen.
   1.440 +The default was to name it
   1.441  .Fn Mail
   1.442  and have it directly in the home directory.
   1.443  .P
   1.444  I've never liked the data storage and the configuration to be intermixed.
   1.445 -They are different kinds of data. One part, are the messages,
   1.446 -which are the data to operate on. The other part, are the personal
   1.447 +They are different kinds of data.
   1.448 +One part, are the messages,
   1.449 +which are the data to operate on.
   1.450 +The other part, are the personal
   1.451  configuration files, which are able to change the behavior of the operations.
   1.452  The actual operations are defined in the profile, however.
   1.453  .P
   1.454 @@ -2175,7 +2213,8 @@
   1.455  messages, but, unlike in MH, nothing else.
   1.456  Its location still is user-chosen, with the default name
   1.457  .Fn Mail ,
   1.458 -in the user's home directory. This is much similar to the case in nmh.
   1.459 +in the user's home directory.
   1.460 +This is much similar to the case in nmh.
   1.461  The configuration files, however, are grouped together in the new directory
   1.462  .Fn \&.mmh
   1.463  in the user's home directory.
   1.464 @@ -2188,8 +2227,10 @@
   1.465  The naming changed with the relocation.
   1.466  The directory where everything, except the profile, had been stored (\c
   1.467  .Fn $HOME/Mail ),
   1.468 -used to be called \fIMH directory\fP. Now, this directory is called the
   1.469 -user's \fImail storage\fP. The name \fImmh directory\fP is now given to
   1.470 +used to be called \fIMH directory\fP.
   1.471 +Now, this directory is called the
   1.472 +user's \fImail storage\fP.
   1.473 +The name \fImmh directory\fP is now given to
   1.474  the new directory
   1.475  (\c
   1.476  .Fn $HOME/.mmh ),
   1.477 @@ -2198,7 +2239,8 @@
   1.478  The separation of the files by type of content is logical and convenient.
   1.479  There are no functional differences as any possible setup known to me
   1.480  can be implemented with both approaches, although likely a bit easier
   1.481 -with the new approach. The main goal of the change had been to provide
   1.482 +with the new approach.
   1.483 +The main goal of the change had been to provide
   1.484  sensible storage locations for any type of personal mmh file.
   1.485  .P
   1.486  In order for one user to have multiple MH setups, he can use the
   1.487 @@ -2226,8 +2268,10 @@
   1.488  Besides providing a more consistent feel (which simply is the result
   1.489  of being designed anew), the set of personal configuration files can
   1.490  be chosen independently from the profile (including mail storage location)
   1.491 -and context, now. Being it relevant for practical use or not, it
   1.492 -de-facto is an improvement. However, the main achievement is the
   1.493 +and context, now.
   1.494 +Being it relevant for practical use or not, it
   1.495 +de-facto is an improvement.
   1.496 +However, the main achievement is the
   1.497  split between mail storage and personal configuration files.
   1.498  
   1.499  
   1.500 @@ -2260,17 +2304,22 @@
   1.501  Historically, MH provided exactly one draft message, named
   1.502  .Fn draft
   1.503  and
   1.504 -being located in the MH directory. When starting to compose another message
   1.505 +being located in the MH directory.
   1.506 +When starting to compose another message
   1.507  before the former one was sent, the user had been questioned whether to use,
   1.508 -refile or replace the old draft. Working on multiple drafts at the same time
   1.509 -was impossible. One could only work on them in alteration by refiling the
   1.510 -previous one to some directory and fetching some other one for reediting. 
   1.511 +refile or replace the old draft.
   1.512 +Working on multiple drafts at the same time
   1.513 +was impossible.
   1.514 +One could only work on them in alteration by refiling the
   1.515 +previous one to some directory and fetching some other one for reediting.
   1.516  This manual draft management needed to be done each time the user wanted
   1.517  to switch between editing one draft to editing another.
   1.518  .P
   1.519  To allow true parallel editing of drafts, in a straight forward way, the
   1.520 -draft folder facility exists. It had been introduced already in July 1984
   1.521 -by Marshall T. Rose. The facility was deactivated by default.
   1.522 +draft folder facility exists.
   1.523 +It had been introduced already in July 1984
   1.524 +by Marshall T. Rose.
   1.525 +The facility was deactivated by default.
   1.526  Even in nmh, the draft folder facility remained deactivated by default.
   1.527  At least, Richard Coleman added the man page
   1.528  .Mp mh-draft(5)
   1.529 @@ -2278,29 +2327,39 @@
   1.530  the feature well.
   1.531  .P
   1.532  The only advantage of not using the draft folder facility is the static
   1.533 -name of the draft file. This could be an issue for MH front-ends like mh-e.
   1.534 +name of the draft file.
   1.535 +This could be an issue for MH front-ends like mh-e.
   1.536  But as they likely want to provide working on multiple drafts in parallel,
   1.537 -the issue is only concerning compatibility. The aim of nmh to stay compatible
   1.538 +the issue is only concerning compatibility.
   1.539 +The aim of nmh to stay compatible
   1.540  prevented the default activation of the draft folder facility.
   1.541  .P
   1.542  On the other hand, a draft folder is the much more natural concept than
   1.543 -a draft message. MH's mail storage consists of folders and messages,
   1.544 -the messages named with ascending numbers. A draft message breaks with this
   1.545 +a draft message.
   1.546 +MH's mail storage consists of folders and messages,
   1.547 +the messages named with ascending numbers.
   1.548 +A draft message breaks with this
   1.549  concept by introducing a message in a file named
   1.550  .Fn draft .
   1.551  This draft
   1.552 -message is special. It can not be simply listed with the available tools,
   1.553 -but instead requires special switches. I.e. corner-cases were
   1.554 -introduced. A draft folder, in contrast, does not introduce such
   1.555 -corner-cases. The available tools can operate on the messages within that
   1.556 -folder like on any messages within any mail folders. The only difference
   1.557 +message is special.
   1.558 +It can not be simply listed with the available tools,
   1.559 +but instead requires special switches.
   1.560 +I.e. corner-cases were
   1.561 +introduced.
   1.562 +A draft folder, in contrast, does not introduce such
   1.563 +corner-cases.
   1.564 +The available tools can operate on the messages within that
   1.565 +folder like on any messages within any mail folders.
   1.566 +The only difference
   1.567  is the fact that the default folder for
   1.568  .Pn send
   1.569  is the draft folder,
   1.570  instead of the current folder, like for all other tools.
   1.571  .P
   1.572  The trivial part of the change was activating the draft folder facility
   1.573 -by default and setting a default name for this folder. Obviously, I chose
   1.574 +by default and setting a default name for this folder.
   1.575 +Obviously, I chose
   1.576  the name
   1.577  .Fn +drafts .
   1.578  This made the
   1.579 @@ -2318,11 +2377,16 @@
   1.580  still has its
   1.581  .Sw -use
   1.582  switch for switching between its two modes: (1) Compose a new
   1.583 -draft, possibly by taking some existing message as a form. (2) Modify
   1.584 -an existing draft. In either case, the behavior of
   1.585 +draft, possibly by taking some existing message as a form.
   1.586 +(2) Modify
   1.587 +an existing draft.
   1.588 +In either case, the behavior of
   1.589  .Pn comp is
   1.590 -deterministic. There is no more need to query the user. I consider this
   1.591 -a major improvement. By making
   1.592 +deterministic.
   1.593 +There is no more need to query the user.
   1.594 +I consider this
   1.595 +a major improvement.
   1.596 +By making
   1.597  .Pn send
   1.598  simply operate on the current
   1.599  message in the draft folder by default, with message and folder both
   1.600 @@ -2337,22 +2401,28 @@
   1.601  .H2 "Trash Folder
   1.602  .P
   1.603  Similar to the situation for drafts is the situation for removed messages.
   1.604 -Historically, a message was deleted by renaming. A specific
   1.605 +Historically, a message was deleted by renaming.
   1.606 +A specific
   1.607  \fIbackup prefix\fP, often comma (\c
   1.608  .Fn , )
   1.609  or hash (\c
   1.610  .Fn # ),
   1.611 -being prepended to the file name. Thus, MH wouldn't recognize the file
   1.612 +being prepended to the file name.
   1.613 +Thus, MH wouldn't recognize the file
   1.614  as a message anymore, as only files whose name consists of digits only
   1.615 -are treated as messages. The removed messages remained as files in the
   1.616 +are treated as messages.
   1.617 +The removed messages remained as files in the
   1.618  same directory and needed some maintenance job to truly delete them after
   1.619 -some grace time. Usually, by running a command similar to
   1.620 +some grace time.
   1.621 +Usually, by running a command similar to
   1.622  .VS
   1.623  find /home/user/Mail -ctime +7 -name ',*' | xargs rm
   1.624  VE
   1.625 -in a cron job. Within the grace time interval
   1.626 +in a cron job.
   1.627 +Within the grace time interval
   1.628  the original message could be restored by stripping the
   1.629 -the backup prefix from the file name. If however, the last message of
   1.630 +the backup prefix from the file name.
   1.631 +If however, the last message of
   1.632  a folder is been removed \(en say message
   1.633  .Fn 6
   1.634  becomes file
   1.635 @@ -2377,17 +2447,20 @@
   1.636  It could be set to any command, which would care for the mail removal
   1.637  instead of taking the default action, described above.
   1.638  Refiling the to-be-removed files to some garbage folder was a common
   1.639 -example. Nmh's man page
   1.640 +example.
   1.641 +Nmh's man page
   1.642  .Mp rmm(1)
   1.643  proposes
   1.644  .Cl "refile +d
   1.645  to move messages to the garbage folder and
   1.646  .Cl "rm `mhpath +d all`
   1.647  the empty the garbage folder.
   1.648 -Managing the message removal this way is a sane approach. It keeps
   1.649 +Managing the message removal this way is a sane approach.
   1.650 +It keeps
   1.651  the removed messages in one place, makes it easy to remove the backup
   1.652  files, and, most important, enables the user to use the tools of MH
   1.653 -itself to operate on the removed messages. One can
   1.654 +itself to operate on the removed messages.
   1.655 +One can
   1.656  .Pn scan
   1.657  them,
   1.658  .Pn show
   1.659 @@ -2399,11 +2472,15 @@
   1.660  to switch over from MH tools to Unix tools \(en MH can do it all itself.
   1.661  .P
   1.662  This approach matches perfect with the concepts of MH, thus making
   1.663 -it powerful. Hence, I made it the default. And even more, I also
   1.664 +it powerful.
   1.665 +Hence, I made it the default.
   1.666 +And even more, I also
   1.667  removed the old backup prefix approach, as it is clearly less powerful.
   1.668  Keeping unused alternative in the code is a bad choice as they likely
   1.669 -gather bugs, by not being constantly tested. Also, the increased code
   1.670 -size and more conditions crease the maintenance costs. By strictly
   1.671 +gather bugs, by not being constantly tested.
   1.672 +Also, the increased code
   1.673 +size and more conditions crease the maintenance costs.
   1.674 +By strictly
   1.675  converting to the trash folder approach, I simplified the code base.
   1.676  .Pn rmm
   1.677  calls
   1.678 @@ -2411,7 +2488,8 @@
   1.679  internally to move the to-be-removed
   1.680  message to the trash folder (\c
   1.681  .Fn +trash
   1.682 -by default). Messages
   1.683 +by default).
   1.684 +Messages
   1.685  there can be operated on like on any other message in the storage.
   1.686  The sweep clean, one can use
   1.687  .Cl "rmm -unlink +trash a" ,