1.1 --- a/discussion.roff	Tue Jul 03 22:31:38 2012 +0200
     1.2 +++ b/discussion.roff	Wed Jul 04 12:07:31 2012 +0200
     1.3 @@ -2654,18 +2654,11 @@
     1.4  .Pn refile
     1.5  does not invoke any tools.
     1.6  .P
     1.7 +By generalizing the message removal in the way that it became covered
     1.8 +by the MH concepts made the whole system more powerful.
     1.9  
    1.10  
    1.11  
    1.12 -Keeping unused alternative in the code is a bad choice as they likely
    1.13 -gather bugs, by not being constantly tested.
    1.14 -Also, the increased code
    1.15 -size and more conditions crease the maintenance costs.
    1.16 -
    1.17 -By generalizing the message removal in a way that it becomes covered
    1.18 -by the MH concepts makes the whole system more powerful.
    1.19 -
    1.20 -
    1.21  
    1.22  
    1.23  .H2 "Modern Defaults
    1.24 @@ -2674,19 +2667,19 @@
    1.25  although one can expect every new user wanting to have them active.
    1.26  The reason they are inactive by default is the wish to stay compatible
    1.27  with old versions.
    1.28 -But what is the definition for old versions.
    1.29 -Still, the highly useful draft folder facility is not active by default
    1.30 -although it had been introduced over twenty-five years ago
    1.31 +But what is the definition for old versions?
    1.32 +Still, the highly useful draft folder facility has not been activated
    1.33 +by default although it was introduced over twenty-five years ago.
    1.34  .[
    1.35  rose romine real work
    1.36  .]
    1.37 -\(en the community seems not to care.
    1.38 -This is one of several examples that require new users to build up
    1.39 -their profile before they can access the modern features of nmh.
    1.40 -Without an extensively built-up profile, the setup is hardly usable
    1.41 +The community seems not to care.
    1.42 +This is one of several examples that require new users to first build up
    1.43 +a profile before they can access the modern features of nmh.
    1.44 +Without an extensive profile, the setup is hardly usable
    1.45  for modern emailing.
    1.46  The point is not the customization of the setup,
    1.47 -but the activating of generally useful facilities.
    1.48 +but the need to activate generally useful facilities.
    1.49  .P
    1.50  Yet, the real problem lies less in enabling the features, as this is
    1.51  straight forward as soon as one knows what he wants.
    1.52 @@ -2712,7 +2705,14 @@
    1.53  They suffer hard enough to get used to the toolchest approach,
    1.54  we should spare them further inconveniences.
    1.55  .P
    1.56 -Maintaining compatibility for its own sake is for no good.
    1.57 +Maintaining compatibility for its own sake is bad,
    1.58 +because the code base collects more and more compatibility code.
    1.59 +Sticking to the compatiblity code means remaining limited;
    1.60 +not using it renders it unnecessary.
    1.61 +Keeping unused alternative in the code is a bad choice as they likely
    1.62 +gather bugs, by not being well tested.
    1.63 +Also, the increased code size and the greater number of conditions
    1.64 +increase the maintenance costs.
    1.65  If any MH implementation would be the back-end of widespread
    1.66  email clients with large user bases, compatibility would be more
    1.67  important.
    1.68 @@ -2728,16 +2728,9 @@
    1.69  Hence, mmh invites new users by providing a convenient and modern setup,
    1.70  readily usable out-of-the-box.
    1.71  .P
    1.72 -In mmh, all modern features are active by default.
    1.73 -In consequence, a setup with a profile that defines only the path to the
    1.74 -mail storage, is already convenient to use.
    1.75 -Again, Paul Vixie's ``edginess'' appeal supports the direction I took:
    1.76 -``the `main branch' should just be modern''.
    1.77 -.[
    1.78 -paul vixie edginess nmh-workers
    1.79 -.]
    1.80 -.P
    1.81 -Modern features that are active in mmh by default include: 
    1.82 +In mmh, all modern features are active by default and many previous
    1.83 +approaches are removed or only accessible in manual ways.
    1.84 +New default features include:
    1.85  .BU
    1.86  The attachment system (\c
    1.87  .Hd Attach ).
    1.88 @@ -2757,6 +2750,14 @@
    1.89  .BU
    1.90  Forwarding messages using MIME.
    1.91  .Ci 6e271608b7b9c23771523f88d23a4d3593010cf1
    1.92 +.P
    1.93 +In consequence, a setup with a profile that defines only the path to the
    1.94 +mail storage, is already convenient to use.
    1.95 +Again, Paul Vixie's ``edginess'' appeal supports the direction I took:
    1.96 +``the `main branch' should just be modern''.
    1.97 +.[
    1.98 +paul vixie edginess nmh-workers
    1.99 +.]
   1.100  
   1.101  
   1.102  
   1.103 @@ -2818,7 +2819,7 @@
   1.104  (2) Any other whitespace should consist of spaces.
   1.105  These two rules ensure the integrity of the visual appearance.
   1.106  Although reformatting existing code should be avoided, I did it.
   1.107 -I did not waste time arguing; I just did it.
   1.108 +I did not waste time arguing; I just reformated the code.
   1.109  .Ci a485ed478abbd599d8c9aab48934e7a26733ecb1
   1.110  
   1.111  .U3 "Comments
   1.112 @@ -2848,7 +2849,8 @@
   1.113  VE
   1.114  .Ci 426543622b377fc5d091455cba685e114b6df674
   1.115  .P
   1.116 -The names of the functions explain enough already.
   1.117 +The program code explains enough itself, already.
   1.118 +
   1.119  
   1.120  .U3 "Names
   1.121  .P
   1.122 @@ -2919,14 +2921,19 @@
   1.123  
   1.124  .H2 "Structural Rework
   1.125  .P
   1.126 -
   1.127 -.U3 "Rework of \f(CWanno\fP
   1.128 +Although the stylistic changes described up to here improve the
   1.129 +readability of the source code, all of them are changes ``in the small''.
   1.130 +Structural changes affect a much larger area.
   1.131 +They are more difficult to do but lead to larger improvements,
   1.132 +especially as they influence the outer shape of the tools as well.
   1.133  .P
   1.134  At the end of their chapter on style,
   1.135  Kernighan and Pike ask: ``But why worry about style?''
   1.136 -The following example of my rework of
   1.137 -.Pn anno
   1.138 -provides an answer why style is important in the first place.
   1.139 +Following are two examples of structural rework that show
   1.140 +why style is important in the first place.
   1.141 +
   1.142 +
   1.143 +.U3 "Rework of \f(CWanno\fP
   1.144  .P
   1.145  Until 2002,
   1.146  .Pn anno