1.1 --- a/discussion.roff	Tue Jul 10 22:30:17 2012 +0200
     1.2 +++ b/discussion.roff	Tue Jul 10 23:13:45 2012 +0200
     1.3 @@ -1657,8 +1657,8 @@
     1.4  Hence, others can comprehend my view and argue for undoing the change
     1.5  if I have missed an important aspect.
     1.6  I was quick in dropping parts.
     1.7 -I rather re-included falsely dropped parts than going at a slower pace.
     1.8 -Mmh is experimental work; it required tough decisions.
     1.9 +I rather include falsely dropped parts again, than going at a slower pace.
    1.10 +Mmh is experimental work; it requires tough decisions.
    1.11  .\" XXX ``exp. work'' schon oft gesagt
    1.12  
    1.13  
    1.14 @@ -1970,8 +1970,8 @@
    1.15  The conversion to MIME is invisible to the user.
    1.16  The draft stored in the draft folder is always in source form with
    1.17  attachment headers.
    1.18 -If the MIMEification fails, for instance because the file to attach
    1.19 -is not accessible, the original draft is not changed.
    1.20 +If the MIMEification fails (e.g. because the file to attach
    1.21 +is not accessible) the original draft is not changed.
    1.22  .P
    1.23  The attachment system handles the forwarding of messages, too.
    1.24  If the attachment header value starts with a plus character (`\fL+\fP'),
    1.25 @@ -1992,7 +1992,7 @@
    1.26  .Pe automimeproc
    1.27  profile entry could be specified to have the `mime' command invoked
    1.28  automatically each time.
    1.29 -Unfortunately, this approach conflicted with attachment system
    1.30 +Unfortunately, this approach conflicted with the attachment system
    1.31  because the draft would already be in MIME format at the time
    1.32  when the attachment system wanted to MIMEify it.
    1.33  To use nmh's attachment system, `mime' must not be called at the
    1.34 @@ -2048,7 +2048,7 @@
    1.35  partly intelligent work.
    1.36  Forcing the user to find out the correct MIME type,
    1.37  forces him to do partly mechanical work.
    1.38 -Letting the computer do the work, can lead to bad choices for difficult
    1.39 +Letting the computer do the work can lead to bad choices for difficult
    1.40  content.
    1.41  For mmh, the latter option was chosen.
    1.42  .P
    1.43 @@ -2235,6 +2235,7 @@
    1.44  .Pn show
    1.45  program, because it was not capable to display MIME messages
    1.46  and is no longer part of mmh.
    1.47 +.\" XXX ref to other section
    1.48  Although
    1.49  .Pn mhshow
    1.50  was renamed to
    1.51 @@ -2242,7 +2243,6 @@
    1.52  in mmh, this section uses the name
    1.53  .Pn mhshow ,
    1.54  in order to avoid confusion.
    1.55 -.\" XXX ref to other section
    1.56  .P
    1.57  In mmh, the basic idea is that
    1.58  .Pn mhshow
    1.59 @@ -2286,7 +2286,7 @@
    1.60  .Sw -serialonly
    1.61  switch of
    1.62  .Pn mhshow .
    1.63 -As MIME parts are always processed exclusively , i.e. serially,
    1.64 +As MIME parts are always processed exclusively, i.e. serially,
    1.65  the `%e' escape in
    1.66  .Pe mhshow-show-*
    1.67  profile entries became useless and was thus removed.
    1.68 @@ -2765,7 +2765,7 @@
    1.69  before they truly used the system,
    1.70  although they had been motivated in the beginning.
    1.71  They suffer hard enough to get used to the tool chest approach,
    1.72 -we should spare them further inconveniences.
    1.73 +we developers should spare them further inconveniences.
    1.74  .P
    1.75  Maintaining compatibility for its own sake is bad,
    1.76  because the code base collects more and more compatibility code.
    1.77 @@ -3813,7 +3813,7 @@
    1.78  The source code of the mmh tools is located in the
    1.79  .Fn uip
    1.80  (``user interface programs'') directory.
    1.81 -Each tools has a source file with the same name.
    1.82 +Each tools has a source file with the name of the command.
    1.83  For example,
    1.84  .Pn rmm
    1.85  is built from
    1.86 @@ -3841,7 +3841,7 @@
    1.87  Most of the mmh tools, however, are simple and straight-forward programs.
    1.88  With the exception of the MIME handling tools,
    1.89  .Pn pick
    1.90 -is the largest tools.
    1.91 +is the largest tool.
    1.92  It contains 1\|037 lines of source code (measured with
    1.93  .Pn sloccount ), excluding the MH library.
    1.94  Only the MIME handling tools (\c
    1.95 @@ -3854,9 +3854,9 @@
    1.96  source files seldom leads to better readability.
    1.97  For such tools, splitting makes sense
    1.98  when parts of the code are reused in other programs,
    1.99 -and the reused code fragment is not general enough
   1.100 -for including it in the MH library,
   1.101 -or, if the code has dependencies on a library that only few programs need.
   1.102 +and the reused code fragment is (1) not general enough
   1.103 +for including it in the MH library
   1.104 +or (2) has dependencies on a library that only few programs need.
   1.105  .Fn uip/packsbr.c ,
   1.106  for instance, provides the core program logic for the
   1.107  .Pn packf
   1.108 @@ -4021,7 +4021,7 @@
   1.109  does annotate and send messages.
   1.110  In nmh, there surely exists the tool
   1.111  .Pn send ,
   1.112 -which does (almost) only send messages.
   1.113 +which does mainly send messages.
   1.114  But
   1.115  .Pn comp
   1.116  and
   1.117 @@ -4034,7 +4034,7 @@
   1.118  .Pn whatnow
   1.119  and
   1.120  .Pn viamail ,
   1.121 -they all (!) have the same message sending function included, too.
   1.122 +they all (!) have the same message sending function included, as well.
   1.123  In result,
   1.124  .Pn comp
   1.125  sends messages without using