1.1 --- a/discussion.roff	Sun Jul 08 17:25:35 2012 +0200
     1.2 +++ b/discussion.roff	Mon Jul 09 11:16:30 2012 +0200
     1.3 @@ -21,10 +21,11 @@
     1.4  I believe that the development of all-in-one mail systems is obsolete.
     1.5  Today, email is too complex to be fully covered by single projects.
     1.6  Such a project won't be able to excel in all aspects.
     1.7 -Instead, the aspects of email should be covered my multiple projects,
     1.8 +Instead, the aspects of email should be covered by multiple projects,
     1.9  which then can be combined to form a complete system.
    1.10  Excellent implementations for the various aspects of email exist already.
    1.11  Just to name three examples: Postfix is a specialized MTA,
    1.12 +.\" XXX homepages verlinken
    1.13  Procmail is a specialized MDA, and Fetchmail is a specialized MRA.
    1.14  I believe that it is best to use such specialized tools instead of
    1.15  providing the same function again as a side-component in the project.
    1.16 @@ -65,7 +66,7 @@
    1.17  .P
    1.18  Focusing on one mail agent role only is motivated by Eric Allman's
    1.19  experience with Sendmail.
    1.20 -He identified limiting Sendmail the MTA task had be one reason for
    1.21 +He identified the limitation of Sendmail to the MTA task as one reason for
    1.22  its success:
    1.23  .[ [
    1.24  costales sendmail
    1.25 @@ -78,12 +79,12 @@
    1.26  were incorporated directly into the user agents.
    1.27  .QE
    1.28  .P
    1.29 -In mmh, the Mail Submission Agent (MSA) is called
    1.30 +In nmh, the Mail Submission Agent (MSA) is called
    1.31  \fIMessage Transfer Service\fP (MTS).
    1.32  This facility, implemented by the
    1.33  .Pn post
    1.34  command, established network connections and spoke SMTP to submit
    1.35 -messages for relay to the outside world.
    1.36 +messages to be relayed to the outside world.
    1.37  The changes in email demanded changes in this part of nmh too.
    1.38  Encryption and authentication for network connections
    1.39  needed to be supported, hence TLS and SASL were introduced into nmh.
    1.40 @@ -126,7 +127,7 @@
    1.41  from remote locations.
    1.42  .Ci ab7b48411962d26439f92f35ed084d3d6275459c
    1.43  Instead, it depends on an external tool to cover this task.
    1.44 -In mmh exist two paths for messages to enter mmh's mail storage:
    1.45 +In mmh, two paths exist for messages to enter mmh's mail storage:
    1.46  (1) Mail can be incorporated with
    1.47  .Pn inc
    1.48  from the system maildrop, or (2) with
    1.49 @@ -139,12 +140,12 @@
    1.50  An external MSA is required to transfer mail to the outside world;
    1.51  an external MRA is required to retrieve mail from remote machines.
    1.52  There exist excellent implementations of such software,
    1.53 -which do this specific task likely better than the internal
    1.54 -versions had done it.
    1.55 -Also, the best suiting programs can be freely chosen.
    1.56 +which likely are superior than the internal version.
    1.57 +Additionally, the best suiting programs can be freely chosen.
    1.58  .P
    1.59  As it had already been possible to use an external MSA or MRA,
    1.60  why not keep the internal version for convenience?
    1.61 +.\" XXX ueberleitung
    1.62  The question whether there is sense in having a fall-back pager in all
    1.63  the command line tools, for the cases when
    1.64  .Pn more
    1.65 @@ -202,6 +203,7 @@
    1.66  that covers the field.
    1.67  Today, this is a reasonable exchange.
    1.68  .P
    1.69 +.\" XXX ueberleitung ???
    1.70  Functionality can be added in three different ways:
    1.71  .BU
    1.72  Implementing the function originally in the project.
    1.73 @@ -210,7 +212,8 @@
    1.74  .BU
    1.75  Depending on a program that provides the function.
    1.76  .P
    1.77 -Whereas adding the function originally to the project increases the
    1.78 +.\" XXX Rework sentence
    1.79 +While adding the function originally to the project increases the
    1.80  code size most and requires most maintenance and development work,
    1.81  it makes the project most independent of other software.
    1.82  Using libraries or external programs require less maintenance work
    1.83 @@ -221,7 +224,7 @@
    1.84  thus information can be exchanged more flexible.
    1.85  Adding code to a project increases maintenance work.
    1.86  .\" XXX ref
    1.87 -Implementing complex functions originally in the project adds
    1.88 +Implementing complex functions in the project itself adds
    1.89  a lot of code.
    1.90  This should be avoided if possible.
    1.91  Hence, the dependencies only change in kind, not in their existence.
    1.92 @@ -230,8 +233,8 @@
    1.93  and
    1.94  .Pn libcrypto /\c
    1.95  .Pn libssl
    1.96 -were treated against program dependencies on an MSA and an MRA.
    1.97 -This also meant treating build-time dependencies against run-time
    1.98 +were traded against program dependencies on an MSA and an MRA.
    1.99 +This also meant trading build-time dependencies against run-time
   1.100  dependencies.
   1.101  Besides program dependencies providing the stronger separation
   1.102  and being more flexible, they also allowed
   1.103 @@ -246,6 +249,7 @@
   1.104  Also, the popular MSAs and MRAs have large communities and a lot
   1.105  of documentation available.
   1.106  Choices for MSAs range from full-featured MTAs like
   1.107 +.\" XXX refs
   1.108  .I Postfix
   1.109  over mid-size MTAs like
   1.110  .I masqmail
   1.111 @@ -292,7 +296,7 @@
   1.112  was removed
   1.113  .Ci 14767c94b3827be7c867196467ed7aea5f6f49b0
   1.114  because its use case of writing to the user's terminal
   1.115 -on receiving of mail is obsolete.
   1.116 +on receival of mail is obsolete.
   1.117  If users like to be informed of new mail, the shell's
   1.118  .Ev MAILPATH
   1.119  variable or graphical notifications are technically more appealing.
   1.120 @@ -305,6 +309,7 @@
   1.121  VE
   1.122  .BU
   1.123  .Pn viamail
   1.124 +.\" XXX was macht viamail
   1.125  was removed
   1.126  .Ci eda72d6a7a7c20ff123043fb7f19c509ea01f932
   1.127  when the new attachment system was activated, because
   1.128 @@ -317,6 +322,7 @@
   1.129  .Ci 0e82199cf3c991a173e0ac8aa776efdb3ded61e6
   1.130  .BU
   1.131  .Pn msgchk
   1.132 +.\" XXX was macht msgchk
   1.133  was removed
   1.134  .Ci bb9360ead7eb7a3fedcce2eeedfc660014e41dbe ,
   1.135  because it lost its use case when POP support was removed.
   1.136 @@ -343,11 +349,11 @@
   1.137  .Ci 916690191222433a6923a4be54b0d8f6ac01bd02
   1.138  because the tool was in conflict with the philosophy of MH.
   1.139  It provided an interactive shell to access the features of MH,
   1.140 -but it wasn't just a shell, tailored to the needs of mail handling.
   1.141 +but it wasn't just a shell tailored to the needs of mail handling.
   1.142  Instead it was one large program that had several MH tools built in.
   1.143  This conflicts with the major feature of MH of being a tool chest.
   1.144  .Pn msh 's
   1.145 -main use case had been accessing Bulletin Boards, which have seized to
   1.146 +main use case had been accessing Bulletin Boards, which have ceased to
   1.147  be popular.
   1.148  .P
   1.149  Removing
   1.150 @@ -422,7 +428,7 @@
   1.151  .Pn slocal
   1.152  in need for deeper investigation.
   1.153  In the meanwhile, it remains part of mmh.
   1.154 -That does not hurt because
   1.155 +However, its continued existence is not significant because
   1.156  .Pn slocal
   1.157  is unrelated to the rest of the project.
   1.158  
   1.159 @@ -432,6 +438,7 @@
   1.160  .Id mhshow
   1.161  .P
   1.162  Since the very beginning, already in the first concept paper,
   1.163 +.\" XXX ref!!!
   1.164  .Pn show
   1.165  had been MH's message display program.
   1.166  .Pn show
   1.167 @@ -509,7 +516,7 @@
   1.168  MIME messages, although it is the other way round.
   1.169  As
   1.170  .Pn mhshow
   1.171 -had already be able to display non-MIME messages, it appeared natural
   1.172 +had already been able to display non-MIME messages, it appeared natural
   1.173  to drop
   1.174  .Pn show
   1.175  in favor of using
   1.176 @@ -554,7 +561,8 @@
   1.177  even more natural.
   1.178  Today, mmh's new
   1.179  .Pn show
   1.180 -became the one single message display program again, with the difference
   1.181 +has become the one single message display program once more,
   1.182 +with the difference
   1.183  that today it handles MIME messages as well as non-MIME messages.
   1.184  The outcome of the transition is one program less to maintain,
   1.185  no second display program for users to deal with,
   1.186 @@ -563,10 +571,11 @@
   1.187  Still, removing the old
   1.188  .Pn show
   1.189  hurts in one regard: It had been such a simple program.
   1.190 -Its lean elegance is missing to the new
   1.191 -.Pn show .
   1.192 -But there is no chance;
   1.193 -supporting MIME demands for higher essential complexity.
   1.194 +Its lean elegance is missing from the new
   1.195 +.Pn show ,
   1.196 +.\" XXX
   1.197 +however there is no alternative;
   1.198 +supporting MIME demands higher essential complexity.
   1.199  
   1.200  .ig
   1.201  XXX
   1.202 @@ -591,13 +600,13 @@
   1.203  There is the cost of code complexity to be able to customize.
   1.204  There is the cost of less tested setups, because there are
   1.205  more possible setups and especially corner-cases.
   1.206 -And, there is the cost of choice itself.
   1.207 +Additionally, there is the cost of choice itself.
   1.208  The code complexity directly affects the developers.
   1.209  Less tested code affects both, users and developers.
   1.210 -The problem of choice affects the users, for once by having to
   1.211 -choose, but also by more complex interfaces that require more documentation.
   1.212 -Whenever options add little advantages, they should be considered for
   1.213 -removal.
   1.214 +The problem of choice affects the users, for once by having to choose,
   1.215 +but also by more complex interfaces that require more documentation.
   1.216 +Whenever options add few advantages but increase the complexity of the
   1.217 +system, they should be considered for removal.
   1.218  I have reduced the number of project-specific configure options from 
   1.219  fifteen to three.
   1.220  
   1.221 @@ -611,10 +620,14 @@
   1.222  and
   1.223  .Sw --with-cyrus-sasl
   1.224  had activated the support for transfer encryption and authentication.
   1.225 +.\" XXX cf
   1.226 +.\" XXX gruende kurz wiederholen
   1.227  This is not needed anymore.
   1.228  .Ci fecd5d34f65597a4dfa16aeabea7d74b191532c3
   1.229  .Ci 156d35f6425bea4c1ed3c4c79783dc613379c65b
   1.230  .P
   1.231 +.\" XXX cf
   1.232 +.\" XXX ``For the same reason ...''
   1.233  The configure switch
   1.234  .Sw --enable-pop
   1.235  activated the message retrieval facility.
   1.236 @@ -624,7 +637,7 @@
   1.237  Whereas the code base changes would only slightly change on toggling
   1.238  TLS or SASL support, it changed much on toggling POP support.
   1.239  The changes in the code base could hardly be overviewed.
   1.240 -By having POP support togglable a second code base had been created,
   1.241 +By having POP support togglable, a second code base had been created,
   1.242  one that needed to be tested.
   1.243  This situation is basically similar for the conditional TLS and SASL  
   1.244  code, but there the changes are minor and can yet be overviewed.
   1.245 @@ -638,6 +651,7 @@
   1.246  .Ar smtp
   1.247  or
   1.248  .Ar sendmail .
   1.249 +.\" XXX naechster Satz ganz raus?
   1.250  In mmh this fixed to
   1.251  .Ar sendmail .
   1.252  .Ci f6aa95b724fd8c791164abe7ee5468bf5c34f226
   1.253 @@ -654,6 +668,7 @@
   1.254  The backup prefix is the string that was prepended to message
   1.255  filenames to tag them as deleted.
   1.256  By default it had been the comma character `\f(CW,\fP'.
   1.257 +.\" XXX Zeitlich ordnen
   1.258  In July 2000, Kimmo Suominen introduced
   1.259  the configure option
   1.260  .Sw --with-hash-backup
   1.261 @@ -681,7 +696,7 @@
   1.262  Using the hash as backup prefix can be seen as a precaution against
   1.263  data loss.
   1.264  .P
   1.265 -I removed the configure option but added the profile entry
   1.266 +First, I removed the configure option but added the profile entry
   1.267  .Pe backup-prefix ,
   1.268  which allows to specify an arbitrary string as backup prefix.
   1.269  .Ci 6c40d481d661d532dd527eaf34cebb6d3f8ed086
   1.270 @@ -823,6 +838,7 @@
   1.271  .Ci ecd6d6a20cb7a1507e3a20d6c4cb3a1cf14c6bbf
   1.272  The change removed functionality too, but that is minor to the
   1.273  improvement by dropping the dependency and the complex autoconf code.
   1.274 +.\" XXX argument: slocal ist sowieso nicht teil vom mmh kern
   1.275  
   1.276  .U3 "mh-e Support
   1.277  .P
   1.278 @@ -849,6 +865,7 @@
   1.279  .Ci a7ce7b4a580d77b6c2c4d980812beb589aa4c643
   1.280  Removing the option removed a second code setup that would have
   1.281  needed to be tested.
   1.282 +.\" XXX datum?
   1.283  This change was first done in nmh and thereafter merged into mmh.
   1.284  .P
   1.285  The interface changes in mmh require mh-e to be adjusted in order
   1.286 @@ -918,6 +935,7 @@
   1.287  hadn't supported it already.
   1.288  .Ci 2abae0bfd0ad5bf898461e50aa4b466d641f23d9
   1.289  Username extensions are possible in mmh, but less convenient to use.
   1.290 +.\" XXX covered by next paragraph
   1.291  .\" XXX format file %(getenv USERNAME_EXTENSION)
   1.292  .P
   1.293  The
   1.294 @@ -978,8 +996,8 @@
   1.295  Every program in mmh has two generic switches:
   1.296  .Sw -help ,
   1.297  to print a short message on how to use the program, and 
   1.298 -.Sw -Version ,
   1.299 -to tell what version of mmh the program belongs to.
   1.300 +.Sw -Version
   1.301 +[sic!], to tell what version of mmh the program belongs to.
   1.302  .P
   1.303  Switches change the behavior of programs.
   1.304  Programs that do one thing in one way require no switches.
   1.305 @@ -1050,7 +1068,7 @@
   1.306  (These numbers include two generic switches, help and version.)
   1.307  .P
   1.308  The figure displays the number of switches for each of the tools
   1.309 -that is available in both, nmh and mmh.
   1.310 +that is available in both nmh and mmh.
   1.311  The tools are sorted by the number of switches they had in nmh.
   1.312  Visible and hidden switches were counted,
   1.313  but not the generic help and version switches.
   1.314 @@ -1108,7 +1126,7 @@
   1.315  The only flexibility removed with this change is having multiple
   1.316  draft folders within one profile.
   1.317  I consider this a theoretical problem only.
   1.318 -In the same go, the
   1.319 +At the same time, the
   1.320  .Sw -draft
   1.321  switch of
   1.322  .Pn anno ,
   1.323 @@ -1116,9 +1134,9 @@
   1.324  and
   1.325  .Pn send
   1.326  was removed.
   1.327 -The special-casing of `the' draft message became irrelevant after
   1.328 +The special treatment of \fIthe\fP draft message became irrelevant after
   1.329  the rework of the draft system.
   1.330 -(df. Sec.
   1.331 +(cf. Sec.
   1.332  .Cf draft-folder )
   1.333  Equally,
   1.334  .Pn comp
   1.335 @@ -1270,7 +1288,9 @@
   1.336  .Pn mhlist
   1.337  were removed, doing real size calculations always now
   1.338  .Ci 8d8f1c3abc586c005c904e52c4adbfe694d2201c ,
   1.339 -as
   1.340 +as nmh's
   1.341 +.Mp mhbuild (1)
   1.342 +man page states
   1.343  ``This provides an accurate count at the expense of a small delay.''
   1.344  This small delay is not noticable on modern systems.
   1.345  .P
   1.346 @@ -1303,7 +1323,7 @@
   1.347  switches was completely removed.
   1.348  .Ci d1fefd9f614e4dc3cda16da6c69133c1b2005269
   1.349  External MIME parts are rare today, having a caching facility
   1.350 -for them is appears to be unnecessary.
   1.351 +for them appears to be unnecessary.
   1.352  .P
   1.353  In pre-MIME times,
   1.354  .Pn mhl
   1.355 @@ -1322,7 +1342,7 @@
   1.356  .P
   1.357  .Pn folder 's
   1.358  data output is self-explaining enough that
   1.359 -displaying the header line makes few sense.
   1.360 +displaying the header line makes little sense.
   1.361  Hence, the
   1.362  .Sw -[no]header
   1.363  switch was removed and headers are never printed.
   1.364 @@ -1379,7 +1399,7 @@
   1.365  with an empty argument.
   1.366  .Ci 75fca31a5b9d5c1a99c74ab14c94438d8852fba9
   1.367  (Specifying
   1.368 -.Cl "-editor true
   1.369 +.Cl "-editor /bin/true
   1.370  is nearly the same, only differing by the previous editor being set.)
   1.371  .P
   1.372  The more important change is the removal of the
   1.373 @@ -1404,7 +1424,7 @@
   1.374  .Sw -nowhatnowproc
   1.375  switch creates only a draft message.
   1.376  As
   1.377 -.Cl "-whatnowproc true
   1.378 +.Cl "-whatnowproc /bin/true
   1.379  causes the same behavior, the
   1.380  .Sw -nowhatnowproc
   1.381  switch was removed for being redundant.
   1.382 @@ -1454,6 +1474,7 @@
   1.383  nor page the output itself (\c
   1.384  .Sw -length
   1.385  .Ci 5b9d883db0318ed2b84bb82dee880d7381f99188 ).
   1.386 +.\" XXX Ref
   1.387  Generally, the pager to use is no longer specified with the
   1.388  .Sw -[no]moreproc
   1.389  command line switches for
   1.390 @@ -1507,6 +1528,7 @@
   1.391  by Rose and
   1.392  ``Lists messages in reverse order with the `\-reverse' switch.
   1.393  This should be considered a bug.'' by Romine in the documentation.
   1.394 +.\" XXX Ref: welche datei genau.
   1.395  The question remains why neither Rose and Romine had fixed this
   1.396  bug in the eighties when they wrote these comments nor has anyone
   1.397  thereafter.
   1.398 @@ -1563,8 +1585,8 @@
   1.399  .\" --------------------------------------------------------------
   1.400  .H1 "Modernizing
   1.401  .P
   1.402 -In the over thirty years of MH's existence, its code base was
   1.403 -extended more and more.
   1.404 +In the more thirty years of MH's existence, its code base was
   1.405 +increasingly extended.
   1.406  New features entered the project and became alternatives to the
   1.407  existing behavior.
   1.408  Relicts from several decades have gathered in the code base,
   1.409 @@ -1578,13 +1600,15 @@
   1.410  
   1.411  .H2 "Code Relicts
   1.412  .P
   1.413 -My position to drop obsolete functions of mmh, in order to remove old code,
   1.414 -is much more revolutional than the nmh community likes to have it.
   1.415 -Working on an experimental version, I was able to quickly drop
   1.416 +My position regarding the removal of obsolete functions of mmh,
   1.417 +.\" XXX ``in order to remove old code,''
   1.418 +is much more revolutional than the nmh community appreciates.
   1.419 +Working on an experimental version, I was quickly able to drop
   1.420  functionality I considered ancient.
   1.421  The need for consensus with peers would have slowed this process down.
   1.422  Without the need to justify my decisions, I was able to rush forward.
   1.423  In December 2011, Paul Vixie motivated the nmh developers to just
   1.424 +.\" XXX ugs
   1.425  do the work:
   1.426  .[
   1.427  paul vixie edginess nmh-workers
   1.428 @@ -1603,18 +1627,20 @@
   1.429  .LP
   1.430  I did so already in the months before.
   1.431  I pushed forward.
   1.432 +.\" XXX semicolon ?
   1.433  I simply dropped the cruft.
   1.434  .P
   1.435  The decision to drop a feature was based on literature research and
   1.436 -careful thinking, but whether having had contact to this particular
   1.437 +careful thinking, but whether having had contact with this particular
   1.438  feature within my own computer life served as a rule of thumb.
   1.439 -Always, I explained my reasons in the commit messages
   1.440 +I explained my reasons in the commit messages
   1.441  in the version control system.
   1.442  Hence, others can comprehend my view and argue for undoing the change
   1.443  if I have missed an important aspect.
   1.444  I was quick in dropping parts.
   1.445 -I rather re-included falsely dropped parts than going a slower pace.
   1.446 +I rather re-included falsely dropped parts than going at a slower pace.
   1.447  Mmh is experimental work; it required tough decisions.
   1.448 +.\" XXX ``exp. work'' schon oft gesagt
   1.449  
   1.450  
   1.451  .U3 "Forking
   1.452 @@ -1623,9 +1649,9 @@
   1.453  In earlier times
   1.454  .Fu fork()
   1.455  had been an expensive system call, because the process's image needed
   1.456 -to be duplicated completely at once.
   1.457 -This was especially painful in the common case when the image gets
   1.458 -replaced by a call to
   1.459 +to be completely duplicated at once.
   1.460 +This expensive work was especially unnecessary in the commonly occuring
   1.461 +case wherein the image is replaced by a call to
   1.462  .Fu exec()
   1.463  right after having forked the child process.
   1.464  The
   1.465 @@ -1672,7 +1698,7 @@
   1.466  .Fu fork()
   1.467  calls in the code were wrapped into loops to retry the
   1.468  .Fu fork()
   1.469 -several times, to increase the changes to succeed, eventually.
   1.470 +several times, to increase the chances to succeed, eventually.
   1.471  On modern systems, a failing
   1.472  .Fu fork()
   1.473  call is unusual.
   1.474 @@ -1695,7 +1721,7 @@
   1.475  header fields is removed in mmh.
   1.476  .Ci 064527f7b57ab050e5af13e15ad99aeeab125857
   1.477  .BU
   1.478 -Native support for
   1.479 +The native support for
   1.480  .Hd Face
   1.481  header fields has been removed, as well.
   1.482  .Ci 8e5be81f784682822f5e868c1bf3c8624682bd23
   1.483 @@ -1706,7 +1732,7 @@
   1.484  Instead of encoding the image data directly into the header field,
   1.485  it contains the hostname and UDP port where the image
   1.486  date can be retrieved.
   1.487 -There exists even a third Face system,
   1.488 +There is even a third Face system,
   1.489  which is the successor of
   1.490  .Hd X-Face ,
   1.491  although it re-uses the
   1.492 @@ -1750,9 +1776,9 @@
   1.493  but uses a different message delimiter (`\fL\\1\\1\\1\\1\fP',
   1.494  commonly written as `\fL^A^A^A^A\fP', instead of `\fLFrom\0\fP').
   1.495  Mbox is the de-facto standard maildrop format on Unix,
   1.496 -whereas the MMDF maildrop format became forgotten.
   1.497 -I did drop MMDF maildrop format support.
   1.498 -Mbox is the only packed mailbox format supported in mmh.
   1.499 +whereas the MMDF maildrop format is now forgotten.
   1.500 +By dropping the MMDF maildrop format support,
   1.501 +mbox became the only packed mailbox format supported in mmh.
   1.502  .P
   1.503  The simplifications within the code were moderate.
   1.504  Mainly, the reading and writing of MMDF mailbox files was removed.
   1.505 @@ -1773,9 +1799,6 @@
   1.506  is heavily optimized and thus dangerous to touch.
   1.507  The risk of damaging the intricate workings of the optimized code is
   1.508  too high.
   1.509 -.\" XXX: move somewhere else
   1.510 -This problem is known to the developers of nmh, too.
   1.511 -They also avoid touching this minefield.
   1.512  
   1.513  
   1.514  .U3 "Prompter's Control Keys
   1.515 @@ -1812,11 +1835,8 @@
   1.516  .P
   1.517  More of a funny anecdote is a check for being connected to a
   1.518  hardcopy terminal.
   1.519 -It remained in the code until Spring 2012, when I finally removed it
   1.520 +It remained in the code until spring 2012, when I finally removed it
   1.521  .Ci b7764c4a6b71d37918a97594d866258f154017ca .
   1.522 -I would be truly happy to see such a terminal in action today,
   1.523 -maybe even being able to work on it.
   1.524 -But I fear my chances are null.
   1.525  .P
   1.526  The check only prevented a pager to be placed between the printing
   1.527  program (\c
   1.528 @@ -1831,7 +1851,7 @@
   1.529  .Ev PAGER
   1.530  to
   1.531  .Pn cat
   1.532 -does the job.
   1.533 +is sufficient.
   1.534  
   1.535  
   1.536  
   1.537 @@ -1859,7 +1879,9 @@
   1.538  MH's MIME support is a direct implementation of the RFCs.
   1.539  The perception of the topic described in the RFCs is clearly visible
   1.540  in MH's implementation.
   1.541 -In result, MH had all the MIME features but no idea of attachments.
   1.542 +.\" XXX rewrite ``no idea''.
   1.543 +As a result,
   1.544 +MH had all the MIME features but no idea of attachments.
   1.545  But users don't need all the MIME features,
   1.546  they want convenient attachment handling.
   1.547  
   1.548 @@ -1873,8 +1895,8 @@
   1.549  .Fn docs/README-ATTACHMENTS ,
   1.550  he described his motivation to do so as such:
   1.551  .QS
   1.552 -Although nmh contains the necessary functionality for MIME message handing,
   1.553 -the interface to this functionality is pretty obtuse.
   1.554 +Although nmh contains the necessary functionality for MIME message
   1.555 +handing [sic!], the interface to this functionality is pretty obtuse.
   1.556  There's no way that I'm ever going to convince my partner to write
   1.557  .Pn mhbuild
   1.558  composition files!
   1.559 @@ -1909,7 +1931,7 @@
   1.560  It is pre-defined to
   1.561  .Hd Attach .
   1.562  .P
   1.563 -To add an attachment to a draft, simply add an attachment header:
   1.564 +To add an attachment to a draft, a header line needs to be added:
   1.565  .VS
   1.566  To: bob
   1.567  Subject: The file you wanted
   1.568 @@ -1927,7 +1949,7 @@
   1.569  Drafts with attachment headers are converted to MIME automatically by
   1.570  .Pn send .
   1.571  The conversion to MIME is invisible to the user.
   1.572 -The draft stored in the draft folder is always in source form, with
   1.573 +The draft stored in the draft folder is always in source form with
   1.574  attachment headers.
   1.575  If the MIMEification fails, for instance because the file to attach
   1.576  is not accessible, the original draft is not changed.
   1.577 @@ -1936,7 +1958,7 @@
   1.578  If the attachment header value starts with a plus character (`+'),
   1.579  like in
   1.580  .Cl "Attach: +bob 30 42" ,
   1.581 -The given messages in the specified folder will be attached.
   1.582 +the given messages in the specified folder will be attached.
   1.583  This allowed to simplify
   1.584  .Pn forw .
   1.585  .Ci f41f04cf4ceca7355232cf7413e59afafccc9550
   1.586 @@ -1951,7 +1973,7 @@
   1.587  .Pe automimeproc
   1.588  profile entry could be specified to have the `mime' command invoked
   1.589  automatically each time.
   1.590 -Unfortunately, this approach conflicted with with attachment system
   1.591 +Unfortunately, this approach conflicted with attachment system
   1.592  because the draft would already be in MIME format at the time
   1.593  when the attachment system wanted to MIMEify it.
   1.594  To use nmh's attachment system, `mime' must not be called at the
   1.595 @@ -1968,9 +1990,10 @@
   1.596  There is no `mime' command at the WhatNow prompt anymore.
   1.597  The draft will be converted automatically to MIME when either an
   1.598  attachment header or non-ASCII text is present.
   1.599 -Further more, the special meaning of the hash character (`#')
   1.600 -at line beginnings in the draft message is removed.
   1.601 -Users need not at all deal with the whole topic.
   1.602 +Furthermore, the hash character (`#') is not special any more
   1.603 +at line beginnings in the draft message.
   1.604 +.\" XXX REF ?
   1.605 +Users need not concern themselves with the whole topic at all.
   1.606  .P
   1.607  Although the new approach does not anymore support arbitrary MIME
   1.608  compositions directly, the full power of
   1.609 @@ -1985,18 +2008,17 @@
   1.610  Because the resulting draft does neither contain non-ASCII characters
   1.611  nor has it attachment headers, the attachment system will not touch it.
   1.612  .P
   1.613 -The approach taken in mmh is tailored towards todays most common case:
   1.614 -a text part with possibly attachments.
   1.615 -This case is simplified a lot for users.
   1.616 +The approach taken in mmh is tailored towards today's most common case:
   1.617 +a text part, possibly with attachments.
   1.618 +This case was simplified.
   1.619  
   1.620  
   1.621  .U3 "MIME Type Guessing
   1.622  .P
   1.623 -The use of
   1.624 +From the programmer's point of view, the use of
   1.625  .Pn mhbuild
   1.626 -composition drafts had one notable advantage over attachment headers
   1.627 -from the programmer's point of view: The user provides the appropriate
   1.628 -MIME types for files to include.
   1.629 +composition drafts had one notable advantage over attachment headers:
   1.630 +The user provides the appropriate MIME types for files to include.
   1.631  The attachment system needs to find out the correct MIME type itself.
   1.632  This is a difficult task, yet it spares the user irritating work.
   1.633  Determining the correct MIME type of content is partly mechanical,
   1.634 @@ -2026,7 +2048,7 @@
   1.635  Nevertheless, modern versions of GNU
   1.636  .Pn file ,
   1.637  which is prevalent on the popular GNU/Linux systems,
   1.638 -provides MIME type output in machine-readable form.
   1.639 +provide MIME type output in machine-readable form.
   1.640  Although this solution is highly system-dependent,
   1.641  it solves the difficult problem well.
   1.642  On systems where GNU
   1.643 @@ -2050,8 +2072,8 @@
   1.644  `application/octet-stream'.
   1.645  It is not possible in mmh to override the automatic MIME type guessing
   1.646  for a specific file.
   1.647 -To do so, the user would need to know in advance for which file
   1.648 -the automatic guessing does fail, or the system would require interaction.
   1.649 +To do so, either the user would need to know in advance for which file
   1.650 +the automatic guessing fails, or the system would require interaction.
   1.651  I consider both cases impractical.
   1.652  The existing solution should be sufficient.
   1.653  If not, the user may always fall back to
   1.654 @@ -2136,9 +2158,8 @@
   1.655  Users will likely need to invoke
   1.656  .Pn mhstore
   1.657  a second time with
   1.658 -.Sw -force
   1.659 -then.
   1.660 -Eventually, only the user can decide in the concrete case.
   1.661 +.Sw -force .
   1.662 +Eventually, only the user can decide in the specific case.
   1.663  This requires interaction, which I like to avoid if possible.
   1.664  Appending a unique suffix to the filename is another bad option.
   1.665  For now, the behavior remains as it is.
   1.666 @@ -2149,15 +2170,16 @@
   1.667  mode.
   1.668  Instead of storing message/rfc822 parts as files to disk,
   1.669  they are stored as messages into the current mail folder.
   1.670 -The same applies to message/partial, only, the parts are reassembled
   1.671 -automatically before.
   1.672 -Parts of type message/external-body are not automatically retrieved
   1.673 -anymore. Instead, Information on how to retrieve them is output.
   1.674 +The same applies to message/partial, although the parts are
   1.675 +automatically reassembled beforehand.
   1.676 +MIME parts of type message/external-body are not automatically retrieved
   1.677 +anymore.
   1.678 +Instead, information on how to retrieve them is output.
   1.679  Not supporting this rare case saved nearly one thousand lines of code.
   1.680  .Ci 55e1d8c654ee0f7c45b9361ce34617983b454c32
   1.681  .\" XXX mention somewhere else too: (The profile entry `nmh-access-ftp'
   1.682  .\"     and sbr/ruserpass.c for reading ~/.netrc are gone now.)
   1.683 -Not special anymore is `application/octet-stream; type=tar'.
   1.684 +`application/octet-stream; type=tar' is not special anymore.
   1.685  Automatically extracting such MIME parts had been the dangerous part
   1.686  of the
   1.687  .Sw -auto
   1.688 @@ -2186,7 +2208,7 @@
   1.689  .Pn mhshow 's
   1.690  behavior to the modern view on the topic.
   1.691  .P
   1.692 -Note that this section completely ignores the original
   1.693 +One should note that this section completely ignores the original
   1.694  .Pn show
   1.695  program, because it was not capable to display MIME messages
   1.696  and is no longer part of mmh.
   1.697 @@ -2197,6 +2219,7 @@
   1.698  in mmh, this section uses the name
   1.699  .Pn mhshow ,
   1.700  in order to avoid confusion.
   1.701 +.\" XXX ref to other section
   1.702  .P
   1.703  In mmh, the basic idea is that
   1.704  .Pn mhshow