1.1 --- a/ch01.roff	Wed Jun 20 11:48:52 2012 +0200
     1.2 +++ b/ch01.roff	Wed Jun 20 17:57:37 2012 +0200
     1.3 @@ -112,6 +112,39 @@
     1.4  As the MH tool chest was modeled after the Unix tool chest, the
     1.5  properties of the latter apply to the former as well.
     1.6  
     1.7 +
     1.8 +.ig \"XXX
     1.9 +
    1.10 +.P
    1.11 +To ease typing, the switches can be abbreviated as much as the remaining
    1.12 +prefix remains unambiguous.
    1.13 +If in our example no other switch would start with the letter `t', then
    1.14 +.Cl "-truncate" ,
    1.15 +.Cl "-trunc" ,
    1.16 +.Cl "-tr" ,
    1.17 +and
    1.18 +.Cl "-t
    1.19 +would all be the same.
    1.20 +As a result, switches can neither be grouped (as in
    1.21 +.Cl "ls -ltr" )
    1.22 +nor can switch arguments be appended directly to the switch (as in
    1.23 +.Cl "sendmail -q30m" ).
    1.24 +.P
    1.25 +Many switches have negating counter-parts, which start with `no'.
    1.26 +For example
    1.27 +.Cl "-notruncate
    1.28 +inverts the
    1.29 +.Cl "-truncate
    1.30 +switch.
    1.31 +They exist to undo the effect of default switches in the profile.
    1.32 +If the user has chosen to change the default behavior of some tool
    1.33 +by adding a default switch to the profile,
    1.34 +he can still undo this change in behavior by specifying the inverse
    1.35 +switch on the command line.
    1.36 +
    1.37 +..
    1.38 +
    1.39 +
    1.40  .U2 "Using MH
    1.41  .P
    1.42  It is strongly recommended to have a look at the MH Book,

     2.1 --- a/ch03.roff	Wed Jun 20 11:48:52 2012 +0200
     2.2 +++ b/ch03.roff	Wed Jun 20 17:57:37 2012 +0200
     2.3 @@ -1096,7 +1096,7 @@
     2.4  switch, are sufficient.
     2.5  
     2.6  
     2.7 -.U3 "Inplace Editing
     2.8 +.U3 "In Place Editing
     2.9  .P
    2.10  .Pn anno
    2.11  had the switches
    2.12 @@ -1608,32 +1608,6 @@
    2.13  .ig
    2.14  
    2.15  .P
    2.16 -To ease typing, the switches can be abbreviated as much as the remaining
    2.17 -prefix remains unambiguous.
    2.18 -If in our example no other switch would start with the letter `t', then
    2.19 -.Cl "-truncate" ,
    2.20 -.Cl "-trunc" ,
    2.21 -.Cl "-tr" ,
    2.22 -and
    2.23 -.Cl "-t
    2.24 -would all be the same.
    2.25 -As a result, switches can neither be grouped (as in
    2.26 -.Cl "ls -ltr" )
    2.27 -nor can switch arguments be appended directly to the switch (as in
    2.28 -.Cl "sendmail -q30m" ).
    2.29 -.P
    2.30 -Many switches have negating counter-parts, which start with `no'.
    2.31 -For example
    2.32 -.Cl "-notruncate
    2.33 -inverts the
    2.34 -.Cl "-truncate
    2.35 -switch.
    2.36 -They exist to undo the effect of default switches in the profile.
    2.37 -If the user has chosen to change the default behavior of some tool
    2.38 -by adding a default switch to the profile,
    2.39 -he can still undo this change in behavior by specifying the inverse
    2.40 -switch on the command line.
    2.41 -.P
    2.42  In the best case, all switches are unambiguous on the first character,
    2.43  or on the three-letter prefix for the `no' variants.
    2.44  Reducing switch prefix collisions, shortens the necessary prefix length
    2.45 @@ -1643,59 +1617,49 @@
    2.46  ..
    2.47  
    2.48  
    2.49 +.\" XXX: whatnow prompt commands
    2.50 +
    2.51 +
    2.52  
    2.53  
    2.54  .H1 "Modernizing
    2.55 +.P
    2.56 +The code base of mmh originates from the late Seventies.
    2.57 +Through the Eighties, extensive work had been done on it.
    2.58 +In the Nineties, it had been partly reorganized and extended.
    2.59 +Relicts from each decade have gathered in the code base.
    2.60 +My goal was to modernize the code base.
    2.61 +
    2.62 +.P
    2.63 +FIXME functional aspect only here
    2.64 +.P
    2.65 +FIXME ref to `code style' for non-functional aspects.
    2.66  
    2.67  
    2.68  .H2 "Code Relicts
    2.69  .P
    2.70 -The code base of mmh originates from the late Seventies,
    2.71 -had been extensively
    2.72 -worked on in the mid Eighties, and had been partly reorganized and extended
    2.73 -in the Nineties. Relicts of all those times had gathered in the code base.
    2.74 -My goal was to remove any ancient code parts. One part of the task was
    2.75 -converting obsolete code constructs to standard constructs, the other part
    2.76 -was dropping obsolete functions.
    2.77 -.P
    2.78 -As I'm not even thirty years old and have no more than seven years of
    2.79 -Unix experience, I needed to learn about the history in retrospective.
    2.80 -Older people likely have used those ancient constructs themselves
    2.81 -and have suffered from their incompatibilities and have longed for
    2.82 -standardization. Unfortunately, I have only read that others had done so.
    2.83 -This put me in a much more difficult positions when working on the old
    2.84 -code. I needed to recherche what other would have known by heart from
    2.85 -experience. All my programming experience comes from a time past ANSI C
    2.86 -and past POSIX. Although I knew about the times before, I took the
    2.87 -current state implicitly for granted most of the time.
    2.88 -.P
    2.89 -Being aware of
    2.90 -these facts, I rather let people with more historic experience solve the 
    2.91 -task of converting the ancient code constructs to standardized ones.
    2.92 -Luckily, Lyndon Nerenberg focused on this task at the nmh project.
    2.93 -He converted large parts of the code to POSIX constructs, removing
    2.94 -the conditionals compilation for now standardized features.
    2.95 -I'm thankful for this task being solved. I only pulled the changes into
    2.96 -mmh.
    2.97 -.P
    2.98 -The other task \(en dropping ancient functionality to remove old code \(en
    2.99 -I did myself, though. My position to strip mmh to the bare minimum of
   2.100 -frequently used features is much more revolutional than the nmh community
   2.101 -likes it. Without the need to justify my decisions, I was able to quickly
   2.102 +My position to drop obsolete functionality of mmh to remove old code
   2.103 +is much more revolutional than the nmh community likes it.
   2.104 +Without the need to justify my decisions, I was able to quickly
   2.105  remove functionality I considered ancient.
   2.106  The need to discuss my decisions with
   2.107 -peers likely would have slowed this process down. Of course, I researched
   2.108 -if a particular feature really should be dropped. Having not had any
   2.109 +peers likely would have slowed this process down.
   2.110 +Of course, I researched if a particular feature really should be dropped.
   2.111 +Having not had any
   2.112  contact to this feature within my computer life was a first indicator to
   2.113  drop it, but I also asked others and searched the literature for modern
   2.114 -usage of the feature. If it appeared to be truly ancient, I dropped it.
   2.115 +usage of the feature.
   2.116 +If it appeared to be truly ancient, I dropped it.
   2.117  The reason for dropping is always part of the commit message in the
   2.118 -version control system. Thus, it is easy for others to check their
   2.119 +version control system.
   2.120 +Thus, it is easy for others to check their
   2.121  view on the topic with mine and possibly to argue for reinclusion.
   2.122  
   2.123 +
   2.124  .U3 "MMDF maildrop support
   2.125  .P
   2.126 -I did drop any support for the MMDF maildrop format. This type of format
   2.127 +I did drop any support for the MMDF maildrop format.
   2.128 +This type of format
   2.129  is conceptionally similar to the mbox format, but uses four bytes with
   2.130  value 1 (\fL^A^A^A^A\fP) as message delimiter,
   2.131  instead of the string ``\fLFrom\ \fP''.
   2.132 @@ -1703,11 +1667,11 @@
   2.133  format on Unix, but also due to the larger influence of Sendmail than MMDF,
   2.134  the MMDF maildrop format had vanished.
   2.135  .P
   2.136 -The simplifications within the code were only moderate. Switches could
   2.137 -be removed from tools like
   2.138 +The simplifications within the code were only moderate.
   2.139 +Switches could be removed from tools like
   2.140  .L packf ,
   2.141 -which generate packed mailboxes. Only one packed mailbox format remained:
   2.142 -mbox.
   2.143 +which generate packed mailboxes.
   2.144 +Only one packed mailbox format remained: mbox.
   2.145  The most important changes affect the equally named mail parsing routine in
   2.146  .L sbr/m_getfld.c .
   2.147  The direct MMDF code had been removed, but as now only one packed mailbox
   2.148 @@ -1717,18 +1681,21 @@
   2.149  .Fu m_getfld() .
   2.150  Changes beyond a small local scope \(en
   2.151  which restructuring in its core is \(en cause a high risk of damaging
   2.152 -the intricate workings of the optimized code. This problem is know
   2.153 -to the developers of nmh, too. They also avoid touching this minefield
   2.154 -if possible.
   2.155 +the intricate workings of the optimized code.
   2.156 +This problem is know to the developers of nmh, too.
   2.157 +They also avoid touching this minefield if possible.
   2.158  
   2.159  .U3 "UUCP Bang Paths
   2.160  .P
   2.161  More questionably than the former topic is the removal of support for the
   2.162 -UUCP bang path address style. However, the user may translate the bang
   2.163 +UUCP bang path address style.
   2.164 +However, the user may translate the bang
   2.165  paths on retrieval to Internet addresses and the other way on posting
   2.166 -messages. The former can be done my an MDA like procmail; the latter
   2.167 -by a sendmail wrapper. This would ensure that any address handling would
   2.168 -work as expected. However, it might just work well without any
   2.169 +messages.
   2.170 +The former can be done my an MDA like procmail; the latter
   2.171 +by a sendmail wrapper.
   2.172 +This would ensure that any address handling would work as expected.
   2.173 +However, it might just work well without any
   2.174  such modifications, as mmh does not touch addresses much, in general.
   2.175  But I can't ensure as I have never used an environment with bang paths.
   2.176  Also, the behavior might break at any point in further development.
   2.177 @@ -1743,8 +1710,8 @@
   2.178  The check only prevented a pager to be placed between the outputting
   2.179  program (\c
   2.180  .Pn mhl )
   2.181 -and the terminal. This could have been ensured with
   2.182 -the
   2.183 +and the terminal.
   2.184 +This could have been ensured with the
   2.185  .Sw -nomoreproc
   2.186  at the command line statically, too.
   2.187  
   2.188 @@ -1753,7 +1720,8 @@
   2.189  The
   2.190  .Hd Encrypted
   2.191  header field had been introduced by RFC\^822, but already
   2.192 -marked legacy in RFC 2822. It was superseded by FIXME.
   2.193 +marked legacy in RFC 2822.
   2.194 +It was superseded by FIXME.
   2.195  Mmh does no more support this header field.
   2.196  .P
   2.197  Native support for
   2.198 @@ -1907,10 +1875,15 @@
   2.199  Thus, MH had all the MIME features but no idea of attachments.
   2.200  Today, however, users don't need all the MIME features but they want
   2.201  convenient attachment handling.
   2.202 -In order to solve this problem, in 2002, Jon Steinhart had added an
   2.203 -attachment system to nmh.
   2.204 +
   2.205 +.U3 "Composing MIME Messages
   2.206 +.P
   2.207 +In order to improve the situation on the message composing side,
   2.208 +Jon Steinhart had added an attachment system to nmh in 2002.
   2.209  .Ci 7480dbc14bc90f2d872d434205c0784704213252
   2.210 -He described his motivation to do so as such:
   2.211 +In the file
   2.212 +.Fn docs/README-ATTACHMENTS ,
   2.213 +he described his motivation to do so as such:
   2.214  .QS
   2.215  Although nmh contains the necessary functionality for MIME message handing,
   2.216  the interface to this functionality is pretty obtuse.
   2.217 @@ -1918,41 +1891,36 @@
   2.218  .Pn mhbuild
   2.219  composition files!
   2.220  .QE
   2.221 -With this change, the mind model of attachments entered nmh:
   2.222 +.LP
   2.223 +With this change, the mind model of attachments entered nmh.
   2.224 +In the same document:
   2.225  .QS
   2.226  These changes simplify the task of managing attachments on draft files.
   2.227  They allow attachments to be added, listed, and deleted.
   2.228  MIME messages are automatically created when drafts with attachments
   2.229  are sent.
   2.230  .QE
   2.231 -Unfortunately, the system had been deactivated by default,
   2.232 -like any new facilities in nmh.
   2.233 -.\" XXX move this paragraph somewhere else
   2.234 -Just to give one example, for me it took one year of using nmh
   2.235 -before I became aware of the existence of the attachment system.
   2.236 -One could argue that this fact disqualifies my reading of the
   2.237 -documentation.
   2.238 -If I would have installed nmh from source back then, I could agree.
   2.239 -Yet I had used a prepackaged version and had expected that it would
   2.240 -just work.
   2.241 +.LP
   2.242 +Unfortunately, the attachment system,
   2.243 +like any new facilities in nmh,
   2.244 +was deactive by default.
   2.245  .P
   2.246  During my work in Argentina, I tried to improve the attachment system.
   2.247 -Because of great opposition in the nmh community, after long discussions,
   2.248 -my patch died as a proposal on the mailing list.
   2.249 +But, because of great opposition in the nmh community,
   2.250 +my patch died as a proposal on the mailing list, after long discussions.
   2.251  .[
   2.252  nmh-workers attachment proposal
   2.253  .]
   2.254 -In Januar 2012, I applied the patch in an extended form to mmh.
   2.255 +In Januar 2012, I extended the patch and applied it to mmh.
   2.256  .Ci 8ff284ff9167eff8f5349481529332d59ed913b1
   2.257 +In mmh, the attachment system is active by default.
   2.258 +Instead of command line switches, the
   2.259 +.Pe Attachment-Header
   2.260 +profile entry is used to specify
   2.261 +the name of the attachment header field.
   2.262 +It is pre-defined to
   2.263 +.Hd Attach .
   2.264  .P
   2.265 -In mmh, the attachment system is active by default.
   2.266 -There are no command line switches anymore, but a pre-defined attachment
   2.267 -header field.
   2.268 -It is named
   2.269 -.Hd Attach
   2.270 -by default, but can be renamed with the
   2.271 -.Pe Attachment-Header
   2.272 -profile entry.
   2.273  To add an attachment to a draft, simply add an attachment header:
   2.274  .VS
   2.275  To: bob
   2.276 @@ -1962,20 +1930,21 @@
   2.277  Here it is.
   2.278  VE
   2.279  The header field can be added to the draft manually in the editor,
   2.280 -by using the `attach' command at the WhatNow prompt, or with
   2.281 +or by using the `attach' command at the WhatNow prompt, or
   2.282 +non-interactively with
   2.283  .Pn anno :
   2.284  .VS
   2.285 -anno -append -nodate -component Attach -text /path/to/file
   2.286 +anno -append -nodate -component Attach -text /path/to/attachment
   2.287  VE
   2.288 -Drafts with attachment headers are converted to MIME automatically
   2.289 -on sending.
   2.290 -The draft stored in the draft folder is always in source form with
   2.291 +Drafts with attachment headers are converted to MIME automatically by
   2.292 +.Pn send .
   2.293 +The conversion to MIME is invisible to the user.
   2.294 +The draft stored in the draft folder is always in source form, with
   2.295  attachment headers.
   2.296 -The convertion to MIME is done invisible to the user.
   2.297  If the MIMEification fails, for instance because the file to attach
   2.298  is not accessible, the original draft is not changed.
   2.299  .P
   2.300 -Forwarding message is handled by the same attachment system.
   2.301 +The attachment system handles the forwarding of messages, too.
   2.302  If the attachment header value starts with a plus character (`+'),
   2.303  like in
   2.304  .Cl "Attach: +bob 30 42" ,
   2.305 @@ -1986,58 +1955,128 @@
   2.306  .P
   2.307  Closely related to attachments is non-ASCII text content,
   2.308  because it requires MIME too.
   2.309 -In nmh it the user needed to invoke `mime' at the WhatNow prompt
   2.310 +In nmh, the user needed to call `mime' at the WhatNow prompt
   2.311  to have the draft converted to MIME.
   2.312 -This was necessary if the draft contained non-ASCII characters.
   2.313 +This was necessary whenever the draft contained non-ASCII characters.
   2.314  If the user did not call `mime', a broken message would be sent.
   2.315  Therefore, the
   2.316  .Pe automimeproc
   2.317  profile entry could be specified to have the `mime' command invoked
   2.318 -automatically for each message.
   2.319 +automatically each time.
   2.320  Unfortunately, this approach conflicted with with attachment system
   2.321  because the draft would already be in MIME format at the time
   2.322  when the attachment system wanted to MIMEify it.
   2.323 -To use the attachment system, the user must not run `mime' at the
   2.324 -WhatNow prompt nor have
   2.325 +To use nmh's attachment system, `mime' must not be called at the
   2.326 +WhatNow prompt and
   2.327  .Pe automimeproc
   2.328 -set in the profile.
   2.329 +must not be set in the profile.
   2.330  But then the case of non-ASCII text without attachment headers was
   2.331  not caught.
   2.332 -All in all a bad solution.
   2.333 -My patch from December 2010 already solved this situation.
   2.334 +All in all, the solution was complex and irritating.
   2.335 +My patch from December 2010 would have simplified the situation.
   2.336 +.P
   2.337  Mmh's current solution is even more elaborate.
   2.338  Any necessary MIMEification is done automatically.
   2.339  There is no `mime' command at the WhatNow prompt anymore.
   2.340 -The draft will be converted to MIME when either an attachment header
   2.341 -or non-ASCII text is present.
   2.342 +The draft will be converted automatically to MIME when either an
   2.343 +attachment header or non-ASCII text is present.
   2.344  Further more, the special meaning of the hash character (`#')
   2.345 -at the beginning of the line in the draft message is removed.
   2.346 -The user needs not at all deal about the topic.
   2.347 +at line beginnings in the draft message is removed.
   2.348 +Users need not at all deal with the whole topic.
   2.349  .P
   2.350 -This improvement has a price: The new approach does not directly
   2.351 -support arbitrary MIME compositions.
   2.352 -Nonetheless, the full power of
   2.353 +Although the new approach does not anymore support arbitrary MIME
   2.354 +compositions directly, the full power of
   2.355  .Pn mhbuild
   2.356  can still be accessed.
   2.357 -As long as no attachment headers are included, the user can create a
   2.358 -nonlimited
   2.359 +Given no attachment headers are included, the user can create
   2.360  .Pn mhbuild
   2.361 -composition draft like in nmh.
   2.362 +composition drafts like in nmh.
   2.363  Then, at the WhatNow prompt, he needs to invoke
   2.364  .Cl "edit mhbuild
   2.365  to convert it to MIME.
   2.366 -Because the resulting draft does only contain ASCII characters
   2.367 -and has no attachment headers, the attachment system will not touch it.
   2.368 +Because the resulting draft does neither contain non-aASCII characters
   2.369 +nor has it attachment headers, the attachment system will not touch it.
   2.370  .P
   2.371  The approach taken in mmh is taylored towards todays most common case:
   2.372  a text part with possibly attachments.
   2.373 -Still, the full power of
   2.374 +This case is simplified a lot for users.
   2.375 +
   2.376 +.U3 "MIME Type Guessing
   2.377 +.P
   2.378 +The use of
   2.379  .Pn mhbuild
   2.380 -can be accessed with a bit of overhead.
   2.381 +composition drafts had one notable advantage over attachment headers
   2.382 +from the programmer's point of view: The user provides the appropriate
   2.383 +MIME types for files to include.
   2.384 +The attachment system needs to find out the correct MIME type itself.
   2.385 +This is a difficult task, yet it spares the user irritating work.
   2.386 +Determining the correct MIME type of content is partly mechanical,
   2.387 +partly intelligent work.
   2.388 +Forcing the user to find out the correct MIME type,
   2.389 +forces him to do partly mechanical work.
   2.390 +Letting the computer do the work, can lead to bad choices for difficult
   2.391 +content.
   2.392 +For mmh, the latter option was chosen.
   2.393 +.P
   2.394 +Determining the MIME type by the suffix of the file name is a dumb
   2.395 +approach, yet it is simple to implement and provides good results
   2.396 +for the common cases.
   2.397 +Mmh implements this approach in the
   2.398 +.Pn print-mimetype
   2.399 +script.
   2.400 +Using it is the default choice.
   2.401 +.P
   2.402 +A far better but less portable approach is the use of
   2.403 +.Pn file .
   2.404 +This standard tool tries to determine the type of files.
   2.405 +Unfortunately, its capabilities and accuracy varies from system to system.
   2.406 +Additionally, its output was only intended for human beings,
   2.407 +but not to be used by programs.
   2.408 +It varies much.
   2.409 +Nevertheless, modern versions of GNU
   2.410 +.Pn file ,
   2.411 +which is prevalent on the popular GNU/Linux systems,
   2.412 +provides MIME type output in machine-readable form.
   2.413 +Although this solution is highly system-dependent,
   2.414 +it solves the difficult problem well.
   2.415 +On systems where GNU
   2.416 +.Pn file ,
   2.417 +version 5.04 or higher, is available it should be used.
   2.418 +One needs to specify the following profile entry to do so:
   2.419 +.VS
   2.420 +Mime-Type-Query: file -b --mime
   2.421 +VE
   2.422 +.LP
   2.423 +Other versions of
   2.424 +.Pn file
   2.425 +might possibly be usable with wrapper scripts to reformat the output.
   2.426 +The diversity among
   2.427 +.Pn file
   2.428 +implementations is great; one needs to check the local variant.
   2.429 +.P
   2.430 +If no MIME type can be determined, text content gets sent as
   2.431 +`text/plain' and anything else under the generic fall-back type
   2.432 +`application/octet-stream'.
   2.433 +It is not possible in mmh to override the automatic MIME type guessing
   2.434 +for a specific file.
   2.435 +To do so, the user would need to know in advance for which file
   2.436 +the automatic guessing does fail, or the system would require interaction.
   2.437 +I consider both cases impractical.
   2.438 +The existing solution should be sufficient.
   2.439 +If not, the user may always fall back to
   2.440 +.Pn mhbuild
   2.441 +composition drafts and ignore the attachment system.
   2.442  
   2.443 -.\" XXX: MIME types
   2.444 -.\" XXX: whatnow prompt commands
   2.445 -.\" XXX: anno rework
   2.446 +
   2.447 +.U3 "Storing Attachments
   2.448 +.P
   2.449 +FIXME
   2.450 +
   2.451 +
   2.452 +.U3 "Showing MIME Messages
   2.453 +.P
   2.454 +FIXME
   2.455 +
   2.456  
   2.457  
   2.458  .H2 "Digital Cryptography
   2.459 @@ -2045,10 +2084,16 @@
   2.460  Signing and encryption.
   2.461  
   2.462  
   2.463 -.H2 "Good Defaults
   2.464 +
   2.465 +.H2 "Modern Defaults
   2.466  .P
   2.467 -foo
   2.468 -
   2.469 +Just to give one example, for me it took one year of using nmh
   2.470 +before I became aware of the existence of the attachment system.
   2.471 +One could argue that this fact disqualifies my reading of the
   2.472 +documentation.
   2.473 +If I would have installed nmh from source back then, I could agree.
   2.474 +Yet I had used a prepackaged version and had expected that it would
   2.475 +just work.
   2.476  
   2.477  
   2.478  
   2.479 @@ -2061,6 +2106,36 @@
   2.480  .P
   2.481  POSIX
   2.482  
   2.483 +.U3 "Converting to Standard Code
   2.484 +.P
   2.485 +One part of this task was converting obsolete code constructs
   2.486 +to standard constructs.
   2.487 +As I'm not even thirty years old and have no more than seven years of
   2.488 +Unix experience, I needed to learn about the history in retrospective.
   2.489 +Older people likely have used those ancient constructs themselves
   2.490 +and have suffered from their incompatibilities and have longed for
   2.491 +standardization.
   2.492 +Unfortunately, I have only read that others had done so.
   2.493 +This put me in a much more difficult positions when working on the old
   2.494 +code.
   2.495 +I needed to recherche what other would have known by heart from
   2.496 +experience.
   2.497 +All my programming experience comes from a time past ANSI C
   2.498 +and past POSIX.
   2.499 +Although I knew about the times before, I took the
   2.500 +current state implicitly for granted most of the time.
   2.501 +.P
   2.502 +Being aware of
   2.503 +these facts, I rather let people with more historic experience solve the 
   2.504 +task of converting the ancient code constructs to standardized ones.
   2.505 +Luckily, Lyndon Nerenberg focused on this task at the nmh project.
   2.506 +He converted large parts of the code to POSIX constructs, removing
   2.507 +the conditionals compilation for now standardized features.
   2.508 +I'm thankful for this task being solved. I only pulled the changes into
   2.509 +mmh.
   2.510 +
   2.511 +
   2.512 +
   2.513  
   2.514  .H2 "Separation
   2.515  
   2.516 @@ -2171,6 +2246,9 @@
   2.517  .P
   2.518  Code layout, goto, ...
   2.519  
   2.520 +.P
   2.521 +anno rework
   2.522 +
   2.523  
   2.524  
   2.525