1.1 --- a/discussion.roff	Sat Jun 23 23:53:52 2012 +0200
     1.2 +++ b/discussion.roff	Sun Jun 24 21:42:23 2012 +0200
     1.3 @@ -682,7 +682,7 @@
     1.4  .CW --with-editor=EDITOR
     1.5  .CW --with-pager=PAGER
     1.6  were used to specify the default editor and pager at configure time.
     1.7 -Doing so at configure time made sense in the Eighties,
     1.8 +Doing so at configure time made sense in the eighties,
     1.9  when the set of available editors and pagers varied much across
    1.10  different systems.
    1.11  Today, the situation is more homogeneous.
    1.12 @@ -1066,7 +1066,7 @@
    1.13  A change early in the project was the complete transition from
    1.14  the single draft message to the draft folder facility.
    1.15  .Ci 337338b404931f06f0db2119c9e145e8ca5a9860
    1.16 -The draft folder facility was introduced in the mid-Eighties, when
    1.17 +The draft folder facility was introduced in the mid-eighties, when
    1.18  Rose and Romine called it a ``relatively new feature''.
    1.19  .[
    1.20  rose romine real work
    1.21 @@ -1584,7 +1584,7 @@
    1.22  ``Lists messages in reverse order with the `\-reverse' switch.
    1.23  This should be considered a bug.'' by Romine in the documentation.
    1.24  The question remains why neither Rose and Romine had fixed this
    1.25 -bug in the Eighties when they wrote these comments nor has anyone
    1.26 +bug in the eighties when they wrote these comments nor has anyone
    1.27  thereafter.
    1.28  
    1.29  
    1.30 @@ -1638,9 +1638,9 @@
    1.31  
    1.32  .H1 "Modernizing
    1.33  .P
    1.34 -The code base of mmh originates from the late Seventies.
    1.35 -Through the Eighties, extensive work had been done on it.
    1.36 -In the Nineties, it had been partly reorganized and extended.
    1.37 +The code base of mmh originates from the late seventies.
    1.38 +Through the eighties, extensive work had been done on it.
    1.39 +In the nineties, it was partly reorganized and extended.
    1.40  Relicts from each decade have gathered in the code base.
    1.41  My goal was to modernize the code base.
    1.42  
    1.43 @@ -1652,7 +1652,7 @@
    1.44  
    1.45  .H2 "Code Relicts
    1.46  .P
    1.47 -My position to drop obsolete functionality of mmh to remove old code
    1.48 +My position to drop obsolete functions of mmh, in order to remove old code,
    1.49  is much more revolutional than the nmh community likes to have it.
    1.50  Working on an experimental version, I was able to quickly drop
    1.51  functionality I considered ancient.
    1.52 @@ -1682,20 +1682,23 @@
    1.53  The decision to drop a feature was based on literature research and
    1.54  careful thinking, but whether having had contact to this particular
    1.55  feature within my own computer life served as a rule of thumb.
    1.56 -My reasons are always made clean in the commit message for the
    1.57 -version control system.
    1.58 +Always, I explained my reasons in the commit messages
    1.59 +in the version control system.
    1.60  Hence, others can comprehend my view and argue for undoing the change
    1.61  if I have missed an important aspect.
    1.62 +I was quick in dropping parts.
    1.63 +I rather re-included falsely dropped parts than going a slower pace.
    1.64 +Mmh is experimental work; it required tough decisions.
    1.65  
    1.66  
    1.67  .U3 "Forking
    1.68  .P
    1.69 -In being a tool chest, MH creates many processes.
    1.70 +Being a tool chest, MH creates many processes.
    1.71  In earlier times
    1.72  .Fu fork()
    1.73  had been an expensive system call, because the process's image needed
    1.74  to be duplicated completely at once.
    1.75 -This was especially painfull in the common case when the image gets
    1.76 +This was especially painful in the common case when the image gets
    1.77  replaced by a call to
    1.78  .Fu exec()
    1.79  right after having forked the child process.
    1.80 @@ -1731,54 +1734,59 @@
    1.81  .Fu vfork()
    1.82  with calls to
    1.83  .Fu fork() .
    1.84 +.Ci 40821f5c1316e9205a08375e7075909cc9968e7d
    1.85  .P
    1.86  Related to the costs of
    1.87  .Fu fork()
    1.88  is the probability of its success.
    1.89 -In the Eighties on heavy loaded systems, calls to
    1.90 +In the eighties, on heavy loaded systems, calls to
    1.91  .Fu fork()
    1.92  were prone to failure.
    1.93  Hence, many of the
    1.94  .Fu fork()
    1.95  calls in the code were wrapped into loops to retry the
    1.96  .Fu fork()
    1.97 -several times, for higher changes to succeed, eventually.
    1.98 -On modern systems, failing calls to
    1.99 +several times, to increase the changes to succeed, eventually.
   1.100 +On modern systems, a failing
   1.101  .Fu fork()
   1.102 -are unusual.
   1.103 +call is unusual.
   1.104  Hence, in the rare case when
   1.105  .Fu fork()
   1.106  fails, mmh programs simply abort.
   1.107 +.Ci 5fbf37ee68e018998ada61eeab73e035b26834b6
   1.108  
   1.109  
   1.110 -.U3 "Obsolete Header Fields
   1.111 +.U3 "Header Fields
   1.112  .BU
   1.113  The
   1.114  .Hd Encrypted
   1.115  header field was introduced by RFC\|822,
   1.116 -but already marked legacy in RFC\|2822.
   1.117 -OpenPGP provides the basis for standardized exchange of encrypted
   1.118 +but already marked as legacy in RFC\|2822.
   1.119 +Today, OpenPGP provides the basis for standardized exchange of encrypted
   1.120  messages [RFC\|4880, RFC\|3156].
   1.121 -The support for
   1.122 +Hence, the support for
   1.123  .Hd Encrypted
   1.124  header fields is removed in mmh.
   1.125 +.Ci 064527f7b57ab050e5af13e15ad99aeeab125857
   1.126  .BU
   1.127  Native support for
   1.128  .Hd Face
   1.129  header fields has been removed, as well.
   1.130 +.Ci 8e5be81f784682822f5e868c1bf3c8624682bd23
   1.131  This feature is similar to the
   1.132  .Hd X-Face
   1.133  header field in its intent,
   1.134  but takes a different approach to store the image.
   1.135  Instead of encoding the image data directly into the header field,
   1.136 -the it contains the hostname and UDP port where the image
   1.137 -date could be retrieved.
   1.138 -There is even a third system, invented in 2005.
   1.139 -Although it re-uses the
   1.140 +it contains the hostname and UDP port where the image
   1.141 +date can be retrieved.
   1.142 +There exists even a third Face system,
   1.143 +which is the successor of
   1.144 +.Hd X-Face ,
   1.145 +although it re-uses the
   1.146  .Hd Face
   1.147 -header field, it is the successor of
   1.148 -.Hd X-Face
   1.149 -with support for colored PNG images.
   1.150 +header field.
   1.151 +It was invented in 2005 and supports colored PNG images.
   1.152  None of the Face systems described here is popular today.
   1.153  Hence, mmh has no direct support for them.
   1.154  .BU
   1.155 @@ -1792,18 +1800,19 @@
   1.156  end-to-end relationship is the use of digital cryptography.
   1.157  .\" XXX (RFCs FIXME).
   1.158  On the other hand, transfer protocols should detect corruption during
   1.159 -each transmission. The TCP includes a checksum field therefore.
   1.160 +the transmission.
   1.161 +The TCP includes a checksum field therefore.
   1.162  These two approaches in combinations render the
   1.163  .Hd Content-MD5
   1.164  header field superfluous.
   1.165 -The nmh-workers mailing list archive contains about 4\|200 messages,
   1.166 -ranging from 1992 until today.
   1.167 -Not a single one had a
   1.168 +Not a single one out of 4\|200 messages from two decades
   1.169 +in an nmh-workers mailing list archive contains a
   1.170  .Hd Content-MD5
   1.171  header field.
   1.172  Neither did any of the 60\|000 messages in my personal mail storage.
   1.173  Removing the support for this header field,
   1.174  removed the last place where MD5 computation was needed.
   1.175 +.Ci 31dc797eb5178970d68962ca8939da3fd9a8efda
   1.176  Hence, the MD5 code could be removed as well.
   1.177  Over 500 lines of code vanished by this one change.
   1.178  
   1.179 @@ -1814,21 +1823,24 @@
   1.180  but uses a different message delimiter (`\fL^A^A^A^A\fP' instead of
   1.181  `\fLFrom\0\fP').
   1.182  Mbox is the de-facto standard maildrop format on Unix,
   1.183 -whereas the MMDF maildrop format is hardly still known today.
   1.184 +whereas the MMDF maildrop format became forgotten.
   1.185  I did drop MMDF maildrop format support.
   1.186 +Mbox is the only packed mailbox format supported in mmh.
   1.187  .P
   1.188 -The simplifications within the code were only moderate.
   1.189 -Switches could be removed from
   1.190 -.L packf
   1.191 +The simplifications within the code were moderate.
   1.192 +Mainly, the reading and writing of MMDF mailbox files was removed.
   1.193 +But also, switches of
   1.194 +.Pn packf
   1.195  and
   1.196 -.L rcvpack ,
   1.197 -which generate packed mailboxes.
   1.198 -Only one packed mailbox format remained: mbox.
   1.199 -The more important changes affected the equally named mail parsing
   1.200 -routine in
   1.201 -.Fn sbr/m_getfld.c .
   1.202 -The MMDF code had been removed there, but as now only one packed mailbox
   1.203 -format is left, further code structure simplifications may be possible.
   1.204 +.Pn rcvpack
   1.205 +could be removed.
   1.206 +.Ci 3916ab66ad5d183705ac12357621ea8661afd3c0
   1.207 +In the message parsing function
   1.208 +.Fn sbr/m_getfld.c ,
   1.209 +knowledge of MMDF packed mail boxes was removed.
   1.210 +.Ci 684ec30d81e1223a282764452f4902ed4ad1c754
   1.211 +Further code structure simplifications may be possible there,
   1.212 +because only one single packed mailbox format is left to be supported.
   1.213  I have not worked on them yet because
   1.214  .Fu m_getfld()
   1.215  is heavily optimized and thus dangerous to touch.
   1.216 @@ -1836,7 +1848,7 @@
   1.217  too high.
   1.218  .\" XXX: move somewhere else
   1.219  This problem is know to the developers of nmh, too.
   1.220 -They also avoid touching this minefield if possible.
   1.221 +They also avoid touching this minefield.
   1.222  
   1.223  
   1.224  .U3 "Prompter's Control Keys
   1.225 @@ -1869,28 +1881,30 @@
   1.226  .Ci 0bd9750710cdbab80cfb4036dd87af20afe1552f .
   1.227  
   1.228  
   1.229 -.U3 "Hardcopy terminal support
   1.230 +.U3 "Hardcopy Terminal Support
   1.231  .P
   1.232 -More of a funny anecdote is a check for printing to a
   1.233 -hardcopy terminal that remained in the code until Spring 2012,
   1.234 -when I finally removed it
   1.235 +More of a funny anecdote is a check for being connected to a
   1.236 +hardcopy terminal.
   1.237 +It remained in the code until Spring 2012, when I finally removed it
   1.238  .Ci b7764c4a6b71d37918a97594d866258f154017ca .
   1.239 -I surely would be very happy to see such a terminal in action,
   1.240 -maybe actually being able to work on it, but I fear my chances are null.
   1.241 +I would be truly happy to see such a terminal in action today,
   1.242 +maybe even being able to work on it.
   1.243 +But I fear my chances are null.
   1.244  .P
   1.245 -The check only prevented a pager to be placed between the outputting
   1.246 +The check only prevented a pager to be placed between the printing
   1.247  program (\c
   1.248  .Pn mhl )
   1.249  and the terminal.
   1.250 -In nmh, this could have been ensured with the
   1.251 +In nmh, this could have been ensured statically with the
   1.252  .Sw -nomoreproc
   1.253 -at the command line statically, too.
   1.254 -In mmh, set the profile entry
   1.255 +at the command line, too.
   1.256 +In mmh, seting the profile entry
   1.257  .Pe Pager
   1.258  or the environment variable
   1.259  .Ev PAGER
   1.260  to
   1.261 -.Pn cat .
   1.262 +.Pn cat
   1.263 +does the job.
   1.264  
   1.265  
   1.266  
   1.267 @@ -1899,7 +1913,7 @@
   1.268  .P
   1.269  The mind model of email attachments is unrelated to MIME.
   1.270  Although the MIME RFCs (2045 through 2049) define the technical
   1.271 -requirements for having attachments, they do not mention the the word
   1.272 +requirements for having attachments, they do not mention the word
   1.273  ``attachment''.
   1.274  Instead of attachments, MIME talks about ``multi-part message bodies''
   1.275  [RFC\|2045], a more general concept.
   1.276 @@ -1909,7 +1923,7 @@
   1.277  [RFC\|2046].
   1.278  MIME keeps its descriptions generic;
   1.279  it does not imply specific usage models.
   1.280 -In email one usage model became prevalent: attachments.
   1.281 +One usage model became prevalent: attachments.
   1.282  The idea is having a main text document with files of arbitrary kind
   1.283  attached to it.
   1.284  In MIME terms, this is a multi-part message having a text part first
   1.285 @@ -1918,9 +1932,10 @@
   1.286  MH's MIME support is a direct implementation of the RFCs.
   1.287  The perception of the topic described in the RFCs is clearly visible
   1.288  in MH's implementation.
   1.289 -Thus, MH had all the MIME features but no idea of attachments.
   1.290 -Today, however, users don't need all the MIME features but they want
   1.291 -convenient attachment handling.
   1.292 +In result, MH had all the MIME features but no idea of attachments.
   1.293 +But users don't need all the MIME features,
   1.294 +they want convenient attachment handling.
   1.295 +
   1.296  
   1.297  .U3 "Composing MIME Messages
   1.298  .P