1.1 --- a/discussion.roff	Mon Jul 09 22:32:24 2012 +0200
     1.2 +++ b/discussion.roff	Mon Jul 09 23:42:59 2012 +0200
     1.3 @@ -29,6 +29,7 @@
     1.4  Procmail is a specialized MDA, and Fetchmail is a specialized MRA.
     1.5  I believe that it is best to use such specialized tools instead of
     1.6  providing the same function again as a side-component in the project.
     1.7 +.\" XXX mail agent picture here
     1.8  .P
     1.9  Doing something well, requires to focus on a small set of specific aspects.
    1.10  Under the assumption that focused development produces better results
    1.11 @@ -165,9 +166,9 @@
    1.12  Here, this part of the Unix philosophy was applied not only
    1.13  to the programs but to the project itself.
    1.14  In other words:
    1.15 -``Develop projects that focus on one thing and do it well.''
    1.16 -Projects grown complex should be split for the same reasons programs grown
    1.17 -complex should be split.
    1.18 +Develop projects that focus on one thing and do it well.
    1.19 +Projects grown complex should be split for the same reasons programs
    1.20 +grown complex should be split.
    1.21  If it is conceptionally more elegant to have the MSA and MRA as
    1.22  separate projects then they should be separated.
    1.23  This is the case here, in my opinion.
    1.24 @@ -194,7 +195,7 @@
    1.25  As the mail systems grew even more, parts were split off.
    1.26  In nmh, for instance, the POP server, which was included in the original
    1.27  MH, was removed.
    1.28 -Now is the time to go one step further and split the MSA and MRA off, too.
    1.29 +Now is the time to go one step further and split off the MSA and MRA, too.
    1.30  Not only does this decrease the code size of the project,
    1.31  but, more important, it unburdens mmh of the whole field of
    1.32  message transfer with all its implications for the project.
    1.33 @@ -557,6 +558,7 @@
    1.34  first.
    1.35  (cf. Sec.
    1.36  .Cf mhshow )
    1.37 +.\" XXX code commits?
    1.38  Once the tools behaved more alike, the replacing appeared to be
    1.39  even more natural.
    1.40  Today, mmh's new
    1.41 @@ -647,21 +649,18 @@
    1.42  .P
    1.43  Two other options only specified default configuration values:
    1.44  .Sw --with-mts
    1.45 -defined the default transport service, either
    1.46 -.Ar smtp
    1.47 -or
    1.48 -.Ar sendmail .
    1.49 -.\" XXX naechster Satz ganz raus?
    1.50 -In mmh this fixed to
    1.51 -.Ar sendmail .
    1.52 +defined the default transport service.
    1.53  .Ci f6aa95b724fd8c791164abe7ee5468bf5c34f226
    1.54  With
    1.55  .Sw --with-smtpservers
    1.56 -default SMTP servers for the
    1.57 -.Ar smtp
    1.58 -transport service could be specified.
    1.59 +default SMTP servers could be specified.
    1.60  .Ci 128545e06224233b7e91fc4c83f8830252fe16c9
    1.61 -Both of them became irrelevant.
    1.62 +Both of them became irrelevant when the SMTP transport service was removed.
    1.63 +.\" XXX code ref
    1.64 +In mmh, all messages are handed over to
    1.65 +.Pn sendmail
    1.66 +for transportation.
    1.67 +
    1.68  
    1.69  .U3 "Backup Prefix
    1.70  .P
    1.71 @@ -707,7 +706,7 @@
    1.72  Eventually, however, the new trash folder concept
    1.73  (cf. Sec.
    1.74  .Cf trash-folder )
    1.75 -obsoleted the concept of the backup prefix completely.
    1.76 +removed the need for the backup prefix completely.
    1.77  .Ci 8edc5aaf86f9f77124664f6801bc6c6cdf258173
    1.78  .Ci ca0b3e830b86700d9e5e31b1784de2bdcaf58fc5
    1.79  
    1.80 @@ -997,7 +996,7 @@
    1.81  .Sw -help ,
    1.82  to print a short message on how to use the program, and 
    1.83  .Sw -Version
    1.84 -[sic!], to tell what version of mmh the program belongs to.
    1.85 +(with capital `V'), to tell what version of mmh the program belongs to.
    1.86  .P
    1.87  Switches change the behavior of programs.
    1.88  Programs that do one thing in one way require no switches.
    1.89 @@ -1103,6 +1102,7 @@
    1.90  A change early in the project was the complete transition from
    1.91  the single draft message to the draft folder facility.
    1.92  .Ci 337338b404931f06f0db2119c9e145e8ca5a9860
    1.93 +.\" XXX ref to section ...
    1.94  The draft folder facility was introduced in the mid-eighties, when
    1.95  Rose and Romine called it a ``relatively new feature''.
    1.96  .[
    1.97 @@ -1138,14 +1138,13 @@
    1.98  the rework of the draft system.
    1.99  (cf. Sec.
   1.100  .Cf draft-folder )
   1.101 -Equally,
   1.102 +Furthermore,
   1.103  .Pn comp
   1.104 -lost its
   1.105 +no longer needs a
   1.106  .Sw -file
   1.107 -switch.
   1.108 -The draft folder facility, together with the
   1.109 +switch as the draft folder facility together with the
   1.110  .Sw -form
   1.111 -switch, are sufficient.
   1.112 +switch are sufficient.
   1.113  
   1.114  
   1.115  .U3 "In Place Editing
   1.116 @@ -1189,9 +1188,10 @@
   1.117  Nmh's
   1.118  .Mp burst (1)
   1.119  man page reads:
   1.120 -.sp \n(PDu
   1.121  .QS
   1.122 -If -noinplace is given, each digest is preserved, no table
   1.123 +If
   1.124 +.Sw -noinplace
   1.125 +is given, each digest is preserved, no table
   1.126  of contents is produced, and the messages contained within
   1.127  the digest are placed at the end of the folder. Other messages
   1.128  are not tampered with in any way.
   1.129 @@ -1278,7 +1278,8 @@
   1.130  .P
   1.131  The MIME tools, which were once part of
   1.132  .Pn mhn
   1.133 -[sic!],
   1.134 +.\" XXX
   1.135 +(whatever that stood for),
   1.136  had several switches that added little practical value to the programs.
   1.137  The
   1.138  .Sw -[no]realsize
   1.139 @@ -1410,14 +1411,26 @@
   1.140  man page for
   1.141  .Mp comp (1):
   1.142  .QS
   1.143 -The \-editor editor switch indicates the editor to use for
   1.144 -the initial edit. Upon exiting from the editor, comp will
   1.145 -invoke the whatnow program. See whatnow(1) for a discussion
   1.146 -of available options. The invocation of this program can be
   1.147 -inhibited by using the \-nowhatnowproc switch. (In truth of
   1.148 -fact, it is the whatnow program which starts the initial
   1.149 -edit. Hence, \-nowhatnowproc will prevent any edit from
   1.150 -occurring.)
   1.151 +The
   1.152 +.Sw -editor
   1.153 +.Ar editor
   1.154 +switch indicates the editor to use for
   1.155 +the initial edit. Upon exiting from the editor,
   1.156 +.Pn comp
   1.157 +will invoke the
   1.158 +.Pn whatnow
   1.159 +program. See
   1.160 +.Mp whatnow (1)
   1.161 +for a discussion of available options.
   1.162 +The invocation of this program can be
   1.163 +inhibited by using the
   1.164 +.Sw -nowhatnowproc
   1.165 +switch. (In truth of fact, it is the
   1.166 +.Pn whatnow
   1.167 +program which starts the initial edit.
   1.168 +Hence,
   1.169 +.Sw -nowhatnowproc
   1.170 +will prevent any edit from occurring.)
   1.171  .QE
   1.172  .P
   1.173  Effectively, the
   1.174 @@ -1510,10 +1523,14 @@
   1.175  Normally when a message is refiled, for each destination
   1.176  folder it is assigned the number which is one above the current
   1.177  highest message number in that folder. Use of the
   1.178 -\-preserv [sic!] switch will override this message renaming, and try
   1.179 +.Sw -preserv
   1.180 +[sic!] switch will override this message renaming, and try
   1.181  to preserve the number of the message. If a conflict for a
   1.182 -particular folder occurs when using the \-preserve switch,
   1.183 -then refile will use the next available message number which
   1.184 +particular folder occurs when using the
   1.185 +.Sw -preserve
   1.186 +switch, then
   1.187 +.Pn refile
   1.188 +will use the next available message number which
   1.189  is above the message number you wish to preserve.
   1.190  .QE
   1.191  
   1.192 @@ -1585,7 +1602,7 @@
   1.193  .\" --------------------------------------------------------------
   1.194  .H1 "Modernizing
   1.195  .P
   1.196 -In the more thirty years of MH's existence, its code base was
   1.197 +In the more than thirty years of MH's existence, its code base was
   1.198  increasingly extended.
   1.199  New features entered the project and became alternatives to the
   1.200  existing behavior.
   1.201 @@ -1618,9 +1635,9 @@
   1.202  discuss whether to keep using vfork, just note in [sic!] passing, [...]
   1.203  we don't need a separate branch for removing vmh
   1.204  or ridding ourselves of #ifdef's or removing posix replacement functions
   1.205 -or depending on pure ansi/posix "libc".
   1.206 +or depending on pure ansi/posix ``libc''.
   1.207  .QP
   1.208 -these things should each be a day or two of work and the "main branch"
   1.209 +these things should each be a day or two of work and the ``main branch''
   1.210  should just be modern. [...]
   1.211  let's push forward, aggressively.
   1.212  .QE
   1.213 @@ -2556,10 +2573,9 @@
   1.214  .P
   1.215  Similar to the situation for drafts is the situation for removed messages.
   1.216  Historically, a message was ``deleted'' by prepending a specific
   1.217 -\fIbackup prefix\fP, usually the comma character,
   1.218 -to the file name.
   1.219 -The specific message would vanish from MH because only files with
   1.220 -non-digit characters in their name are not treated as messages.
   1.221 +\fIbackup prefix\fP, usually the comma character, to the file name.
   1.222 +The specific file would then be ignored by MH because only files with
   1.223 +names consisting of digits only are treated as messages.
   1.224  Although files remained in the file system,
   1.225  the messages were no more visible in MH.
   1.226  To truly delete them, a maintenance job is needed.
   1.227 @@ -2570,15 +2586,15 @@
   1.228  VE
   1.229  In such a setup, the original message can be restored
   1.230  within the grace time interval by stripping the
   1.231 -the backup prefix from the file name.
   1.232 -But one can not rely on this statement.
   1.233 +backup prefix from the file name.
   1.234 +But the user can not rely on this statement.
   1.235  If the last message of a folder with six messages (1-6) is removed,
   1.236  message
   1.237  .Fn 6 ,
   1.238  becomes file
   1.239  .Fn ,6 .
   1.240  If then a new message enters the same folder, it will be given
   1.241 -the number one higher than the highest existing message.
   1.242 +the number one higher than the highest message.
   1.243  In this case the message is named
   1.244  .Fn 6
   1.245  then.
   1.246 @@ -2594,12 +2610,12 @@
   1.247  same folder is removed before.'' the statement becomes complex.
   1.248  A user will hardly be able to keep track of any removal to know
   1.249  if the assertion still holds true for a specific file.
   1.250 -The the real mechanism is practically obscure to the user.
   1.251 +In practice, the real mechanism is unclear to the user.
   1.252  The consequences of further removals are not obvious.
   1.253  .P
   1.254  Further more, the backup files are scattered within the whole mail storage.
   1.255  This complicates managing them.
   1.256 -It is possible, with help of
   1.257 +It is possible with the help of
   1.258  .Pn find ,
   1.259  but everything would be more convenient
   1.260  if the deleted messages would be collected in one place.
   1.261 @@ -2609,7 +2625,7 @@
   1.262  (previously named
   1.263  .Pe Delete-Prog )
   1.264  was introduced very early to improve the situation.
   1.265 -It could be set to any command, which would be executed to removed
   1.266 +It could be set to any command, which would be executed to remove
   1.267  the specified messages.
   1.268  This would override the default action, described above.
   1.269  Refiling the to-be-removed files to a garbage folder is the usual example.
   1.270 @@ -2631,7 +2647,7 @@
   1.271  because they are all collected in one place.
   1.272  Existing and removed messages are thus separated more strictly.
   1.273  No backup files are silently overwritten.
   1.274 -Most important is the ability to keep removed messages in the MH domain.
   1.275 +But most important is the ability to keep removed messages in the MH domain.
   1.276  Messages in the trash folder can be listed like those in any other folder.
   1.277  Deleted messages can be displayed like any other messages.
   1.278  Restoring a deleted messages can be done with
   1.279 @@ -2648,7 +2664,7 @@
   1.280  to move the to-be-removed message to the trash folder,
   1.281  .Fn +trash
   1.282  by default.
   1.283 -To sweep it clean, one can use
   1.284 +To sweep it clean, the user can use
   1.285  .Cl "rmm -unlink +trash a" ,
   1.286  where the
   1.287  .Sw -unlink
   1.288 @@ -2667,9 +2683,9 @@
   1.289  .Pn refile ,
   1.290  which used to be the other way round.
   1.291  Yet, the relationship is simpler now.
   1.292 -No more can loops, like described in nmh's man page for
   1.293 +Loops, like described in nmh's man page for
   1.294  .Mp refile (1),
   1.295 -occur:
   1.296 +can no longer occur:
   1.297  .QS
   1.298  Since
   1.299  .Pn refile
   1.300 @@ -3040,10 +3056,13 @@
   1.301  .Sw -list
   1.302  read:
   1.303  .QS
   1.304 -The -list option produces a listing of the field bodies for
   1.305 +The
   1.306 +.Sw -list
   1.307 +option produces a listing of the field bodies for
   1.308  header fields with names matching the specified component,
   1.309 -one per line. The listing is numbered, starting at 1, if
   1.310 -the -number option is also used.
   1.311 +one per line. The listing is numbered, starting at 1, if the
   1.312 +.Sw -number
   1.313 +option is also used.
   1.314  .QE
   1.315  .LP
   1.316  The problem was manifold.
   1.317 @@ -3342,21 +3361,36 @@
   1.318  I asked John Romine and here's what he had to say, which
   1.319  agrees and provides an example that convinces me:
   1.320  .QS
   1.321 -My take on this is that post should not be called by
   1.322 -users directly, and it doesn't read the .mh_profile
   1.323 +My take on this is that
   1.324 +.Pn post
   1.325 +should not be called by users directly, and it doesn't read the
   1.326 +.Fn .mh_profile
   1.327  (only front-end UI programs read the profile).
   1.328  .QP
   1.329 -For example, there can be contexts where post is called
   1.330 -by a helper program (like 'mhmail') which may be run by
   1.331 -a non-MH user.  We don't want this to prompt the user
   1.332 -to create an MH profile, etc.
   1.333 +For example, there can be contexts where
   1.334 +.Pn post
   1.335 +is called by a helper program (like `\c
   1.336 +.Pn mhmail ')
   1.337 +which may be run by a non-MH user.
   1.338 +We don't want this to prompt the user to create an MH profile, etc.
   1.339  .QP
   1.340 -My suggestion would be to have send pass a (hidden)
   1.341 -`\-fileproc proc' option to post if needed.  You could also
   1.342 -use an environment variable (I think send/whatnow do
   1.343 -this).
   1.344 +My suggestion would be to have
   1.345 +.Pn send
   1.346 +pass a (hidden) `\c
   1.347 +.Sw -fileproc
   1.348 +.Ar proc '
   1.349 +option to
   1.350 +.Pn post
   1.351 +if needed.
   1.352 +You could also
   1.353 +use an environment variable (I think
   1.354 +.Pn send /\c
   1.355 +.Pn whatnow
   1.356 +do this).
   1.357  .QE
   1.358 -I think that's the way to go.  My personal preference is to use a command line option, not an environment variable.
   1.359 +I think that's the way to go.
   1.360 +My personal preference is to use a command line option,
   1.361 +not an environment variable.
   1.362  .QE
   1.363  .P
   1.364  To solve the problem of