--- a/ch03.roff	Sat Jun 16 13:31:25 2012 +0200
+++ b/ch03.roff	Sat Jun 16 17:28:11 2012 +0200
@@ -951,12 +951,13 @@
 Switches change the behavior of programs.
 Programs that do one thing in one way require no switches.
 In most cases, doing something in exactly one way is too limiting.
-If it is basically the same task to accomplish, but it should be done
+If there is basically one task to accomplish, but it should be done
 in various ways, switches are a good approach to alter the behavior
 of a program.
 Changing the behavior of programs provides flexibility and customization
-to users, but in the same way it complicates the code, documentation and
+to users, but at the same time it complicates the code, documentation and
 usage of the program.
+.\" XXX: Ref
 Therefore, the number of switches should be kept small.
 A small set of well-chosen switches does no harm.
 But usually, the number of switches increases over time.
@@ -978,51 +979,54 @@
 suffers mightily from this.
 .sp
 .P
-Adding new switches only reluctantly is one part of the counter-action,
-the other is removing hardly used switches.
-Now that there are lots of switches already implemented,
-removing some of them is more important.
+Being reluctant to adding new switches \(en or `options',
+as Rose and Romine call them \(en is one part of a counter-action,
+the other part is removing hardly used switches.
+Nmh's tools had lots of switches already implemented,
+hence, cleaning up by removing some of them was the more important part
+of the counter-action.
 Removing existing functionality is always difficult because it
 breaks programs that use these functions.
 Also, for every obsolete feature, there'll always be someone who still
 uses it and thus opposes its removal.
 This puts the developer into the position,
 where sensible improvements to style are regarded as destructive acts.
-Yet, living with the featurism is far worse, in my eyes.
-Future needs will demand adding new features,
+Yet, living with the featurism is far worse, in my eyes, because
+future needs will demand adding further features,
 worsening the situation more and more.
 Rose and Romine added in a footnote,
 ``[...]
 .Pn send
 will no doubt acquire an endless number of switches in the years to come.''
-Although clearly humorous, the comment displays the nature of
-the problem.
-Though refusing to add any new switches would encounter the problem
-at its root, it is not practical.
-But removing obsolete switches is an effective approach to deal with the
-problem.
-Working on an experimental branch,
-eased this work because I had not to offend users.
+Although clearly humorous, the comment points to the nature of the problem.
+Refusing to add any new switches would encounter the problem at its root,
+but this is not practical.
+New needs will require new switches and it would be unwise to block
+them strictly.
+Nevertheless, removing obsolete switches still is an effective approach
+to deal with the problem.
+Working on an experimental branch without an established user base,
+eased my work because I did not offend users when I removed existing
+funtions.
 .P
 Rose and Romine counted 24 visible and 9 more hidden switches for
 .Pn send .
-At the beginning of mmh, it were 32 visible and 12 hidden ones.
-At the time of writing, mmh's
-.Pn send
-has 7 visible switches and 1 hidden switch.
-(In each of the examples, the two generic help and version switches
-are included.)
+In nmh, they increased up to 32 visible and 12 hidden ones.
+At the time of writing, no more than 7 visible switches and 1 hidden switch
+have remained in mmh's
+.Pn send .
+(These numbers include two generic switches, help and version.)
 .P
-Figure XXX
+Fig. XXX
 .\" XXX Ref
-displays the number of switches for each of the tools that was not
-removed from or newly added to mmh.
-Both, visible and hidden switches, were counted, but
-not the generic help and version switches.
+displays the number of switches for each of the tools that is available
+in both, nmh and mmh.
+Visible as well as hidden switches were counted,
+but not the generic help and version switches.
 Whereas in the beginning of the project, the average tool had 11 switches,
 now it has no more than 5 \(en only half as many.
 If the `no' switches and similar inverse variant are folded onto
-their counter-parts, the numbers are 8 in pre-mmh to 4 now.
+their counter-parts, the average tool has 8 switches in pre-mmh to 4 now.
 The total number of functional switches in mmh dropped from 465
 to 234.
 
@@ -1034,22 +1038,28 @@
 .P
 A part of the switches vanished after functions were removed.
 This was the case for network mail transfer, for instance.
-Sometimes the work flow was the other way:
-The trying to reduce the number of switches suggested the removal of
-functions.
+Sometimes, however, the work flow was the other way:
+I looked through the
+.Mp mh-chart (7)
+man page to identify the tools with apparently too many switches.
+Then considering the value of each of the switches by examining
+the tool's man page and source code, aided by recherche and testing.
+This way, the removal of functions was suggested by the aim to reduce
+the number of switches per command.
+
 
 .U3 "Draft Folder Facility
 .P
 A change early in the project was the completely transition from
 the single draft message to the draft folder facility.
+.Ci 337338b404931f06f0db2119c9e145e8ca5a9860
 The draft folder facility was introduced in the mid-Eighties.
 (Rose and Romine called it a ``relatively new feature''
 .[
 rose romine real work
 .]
 in 1985.)
-Since then, the facility had existed but had remained deactivated
-by default.
+Since then, the facility had existed but was deactivated by default.
 The default activation and the related rework of the tools made it
 possible to remove the
 .Sw -[no]draftfolder ,
@@ -1063,9 +1073,10 @@
 .Pn whatnow ,
 and
 .Pn send .
-The only flexibility removed is having multiple draft folders
-within one profile.
-I consider this only a theoretical setup.
+.Ci 337338b404931f06f0db2119c9e145e8ca5a9860
+The only flexibility removed with this change is having multiple
+draft folders within one profile.
+I consider this a theoretical problem only.
 In the same go, the
 .Sw -draft
 switch of
@@ -1094,12 +1105,13 @@
 .Sw -[no]inplace
 to either annotate the message inplace and thus preserve hard links,
 or annotate a copy to replace the original message, breaking hard links.
-Following the assumption that linked messages are the same message,
-and annotating it should not break the link, the
+Following the assumption that linked messages should truly be the
+same message, and annotating it should not break the link, the
 .Sw -[no]inplace
 switches were removed and the previous default
 .Sw -inplace
 was made the only behavior.
+.Ci c8195849d2e366c569271abb0f5f60f4ebf0b4d0
 The
 .Sw -[no]inplace
 switches of
@@ -1141,6 +1153,7 @@
 it caused.
 .Sw -noinplace
 was chosen to be the definitive behavior.
+.Ci 68a686adeb39223a5e1ad35e4a24890ec053679d
 
 
 .U3 "Forms and Format Strings
@@ -1161,6 +1174,7 @@
 switches were dropped in favor for extending the
 .Sw -form
 switches.
+.Ci f51956be123db66b00138f80464d06f030dbb88d
 If their argument starts with an equal sign (`='),
 then the rest of the argument is taken as a format string,
 otherwise the arguments is treated as the name of a format file.
@@ -1187,6 +1201,7 @@
 .Pn forw
 was completely switched to MIME-type forwarding, thus removing the
 .Sw -[no]format .
+.Ci 6e271608b7b9c23771523f88d23a4d3593010cf1
 For
 .Pn repl ,
 the
@@ -1194,6 +1209,7 @@
 switches were reworked to
 .Sw -[no]filter
 switches.
+.Ci 67411b1f95d6ec987b4c732459e1ba8a8ac192c6
 The
 .Sw -format
 switches of
@@ -1202,6 +1218,7 @@
 .Pn post ,
 which had a third meaning,
 were removed likewise.
+.Ci f3cb7cde0e6f10451b6848678d95860d512224b9
 Eventually, the ambiguity of the
 .Sw -format
 switches was resolved by not anymore having any such switch in mmh.
@@ -1218,7 +1235,9 @@
 .Pn mhbuild
 and
 .Pn mhlist
-were removed, doing real size calculations always now, as
+were removed, doing real size calculations always now
+.Ci 8d8f1c3abc586c005c904e52c4adbfe694d2201c ,
+as
 ``This provides an accurate count at the expense of a small delay.''
 This small delay is not noticable on modern systems.
 .P
@@ -1230,6 +1249,7 @@
 .[
 rfc 1864
 .]
+.Ci 31dc797eb5178970d68962ca8939da3fd9a8efda
 (See Sec. XXX)
 .P
 The
@@ -1239,13 +1259,16 @@
 switches of
 .Pn mhbuild
 were removed because they are considered obsolete.
+.Ci 01a3480928da485b4d6109d36d751dfa71799d58
+.Ci 3363e2624dce0eb8164cf8b3f1ab385c8ff72e88
 .P
 Content caching of external MIME parts, activated with the
 .Sw -rcache
 and
 .Sw -wcache
 switches was completely removed.
-External MIME parts are truly rare today, having a caching facility
+.Ci d1fefd9f614e4dc3cda16da6c69133c1b2005269
+External MIME parts are rare today, having a caching facility
 for them is appears to be unnecessary.
 .P
 In pre-MIME times,
@@ -1255,6 +1278,8 @@
 .Pn mhl
 could be simplified to a large extend, reducing the number of its
 switches from 21 to 6.
+.Ci 350ad6d3542a07639213cf2a4fe524e829c1e7b6
+.Ci 0e46503be3c855bddaeae3843e1b659279c35d70
 
 
 .U3 "Mail Transfer Switches
@@ -1328,11 +1353,15 @@
 switches.
 .Sw -mbox
 is the sole  behavior now.
+.Ci 3916ab66ad5d183705ac12357621ea8661afd3c0
 In the same go,
 .Pn packf
-was reworked (see Sec. XXX) and its
+and
+.Pn rcvpack
+were reworked (see Sec. XXX) and their
 .Sw -file
 switch became unnecessary.
+.Ci ca1023716d4c2ab890696f3e41fa0d94267a940e
 
 
 .U3 "Terminal Magic
@@ -1342,13 +1371,17 @@
 and
 .Pn mhl 's
 .Sw -[no]clear
-switches).
+switches
+.Ci e57b17343dcb3ff373ef4dd089fbe778f0c7c270
+.Ci 943765e7ac5693ae177fd8d2b5a2440e53ce816e ).
 Neither will
 .Pn mhl
 ring the bell (\c
-.Sw -[no]bell )
+.Sw -[no]bell
+.Ci e11983f44e59d8de236affa5b0d0d3067c192e24 )
 nor page the output itself (\c
-.Sw -length ).
+.Sw -length
+.Ci 5b9d883db0318ed2b84bb82dee880d7381f99188 ).
 .P
 Generally, the pager to use is no longer specified with the
 .Sw -[no]moreproc
@@ -1357,6 +1390,7 @@
 and
 .Pn show /\c
 .Pn mhshow .
+.Ci 39e87a75b5c2d3572ec72e717720b44af291e88a
 .P
 .Pn prompter
 lost its
@@ -1374,12 +1408,14 @@
 Hence, the
 .Sw -[no]header
 switch was removed and headers are never printed.
+.Ci 601cc73d1fa05ce96faa728f036d6c51b91701c7
 .P
 In
 .Pn mhlist ,
 the
 .Sw -[no]header
 switches were removed, too.
+.Ci b24f96523aaf60e44e04a3ffb1d22e69a13a602f
 But in this case headers are always printed,
 because the output is not self-explaining.
 .P
@@ -1395,6 +1431,7 @@
 and
 .Pn date ,
 consequently, the switches were removed.
+.Ci c477dc5d1d03fa6d9a8ab3dd3508c63cbddc044e
 .P
 By removing all
 .Sw -header
@@ -1422,6 +1459,7 @@
 was removed, but it can now be replaced by specifying
 .Sw -editor
 with an empty argument.
+.Ci 75fca31a5b9d5c1a99c74ab14c94438d8852fba9
 (Specifying
 .Cl "-editor true
 is nearly the same, only differing by the previous editor being set.)
@@ -1429,6 +1467,7 @@
 The more important change is the removal of the
 .Sw -nowhatnowproc
 switch.
+.Ci ee4f43cf2ef0084ec698e4e87159a94c01940622
 This switch had introduced an awkward behavior, as explained in nmh's
 man page for
 .Mp comp (1):
@@ -1476,6 +1515,7 @@
 I removed the
 .Sw -[no]total
 legacy.
+.Ci ea21fe2c4bd23c639bef251398fae809875732ec
 .BU
 The
 .Sw -subject
@@ -1485,6 +1525,7 @@
 It can be fully replaced by
 .Cl "-textfield subject
 thus it was removed.
+.Ci 00140a3c86e9def69d98ba2ffd4d6e50ef6326ea
 
 
 .U3 "Various
@@ -1494,6 +1535,7 @@
 switch was renamed to
 .Sw -Version
 (with capital `V').
+.Ci 32b2354dbaf4bf934936eb5b102a4a3d2fdd209a
 Every program has the
 .Sw -version
 switch but its first three letters collided with the
@@ -1522,12 +1564,13 @@
 .Sw -[no]reverse
 switches of
 .Pn scan
+.Ci 8edc5aaf86f9f77124664f6801bc6c6cdf258173
 is a bug fix, supported by the comments
 ``\-[no]reverse under #ifdef BERK (I really HATE this)''
 by Rose and
 ``Lists messages in reverse order with the `\-reverse' switch.
 This should be considered a bug.'' by Romine in the documentation.
-The question remaining is why neither Rose and Romine had fixed this
+The question remains why neither Rose and Romine had fixed this
 bug in the Eighties when they wrote these comments nor has anyone
 thereafter.