# HG changeset patch # User markus schnalke # Date 1341396451 -7200 # Node ID 470d5db0c06c2e5ad64911b5b348bae39371f496 # Parent d8adac1ed7d86ce9746a5a6712536f6b9070615c Minor rework. diff -r d8adac1ed7d8 -r 470d5db0c06c discussion.roff --- a/discussion.roff Tue Jul 03 22:31:38 2012 +0200 +++ b/discussion.roff Wed Jul 04 12:07:31 2012 +0200 @@ -2654,18 +2654,11 @@ .Pn refile does not invoke any tools. .P +By generalizing the message removal in the way that it became covered +by the MH concepts made the whole system more powerful. -Keeping unused alternative in the code is a bad choice as they likely -gather bugs, by not being constantly tested. -Also, the increased code -size and more conditions crease the maintenance costs. - -By generalizing the message removal in a way that it becomes covered -by the MH concepts makes the whole system more powerful. - - .H2 "Modern Defaults @@ -2674,19 +2667,19 @@ although one can expect every new user wanting to have them active. The reason they are inactive by default is the wish to stay compatible with old versions. -But what is the definition for old versions. -Still, the highly useful draft folder facility is not active by default -although it had been introduced over twenty-five years ago +But what is the definition for old versions? +Still, the highly useful draft folder facility has not been activated +by default although it was introduced over twenty-five years ago. .[ rose romine real work .] -\(en the community seems not to care. -This is one of several examples that require new users to build up -their profile before they can access the modern features of nmh. -Without an extensively built-up profile, the setup is hardly usable +The community seems not to care. +This is one of several examples that require new users to first build up +a profile before they can access the modern features of nmh. +Without an extensive profile, the setup is hardly usable for modern emailing. The point is not the customization of the setup, -but the activating of generally useful facilities. +but the need to activate generally useful facilities. .P Yet, the real problem lies less in enabling the features, as this is straight forward as soon as one knows what he wants. @@ -2712,7 +2705,14 @@ They suffer hard enough to get used to the toolchest approach, we should spare them further inconveniences. .P -Maintaining compatibility for its own sake is for no good. +Maintaining compatibility for its own sake is bad, +because the code base collects more and more compatibility code. +Sticking to the compatiblity code means remaining limited; +not using it renders it unnecessary. +Keeping unused alternative in the code is a bad choice as they likely +gather bugs, by not being well tested. +Also, the increased code size and the greater number of conditions +increase the maintenance costs. If any MH implementation would be the back-end of widespread email clients with large user bases, compatibility would be more important. @@ -2728,16 +2728,9 @@ Hence, mmh invites new users by providing a convenient and modern setup, readily usable out-of-the-box. .P -In mmh, all modern features are active by default. -In consequence, a setup with a profile that defines only the path to the -mail storage, is already convenient to use. -Again, Paul Vixie's ``edginess'' appeal supports the direction I took: -``the `main branch' should just be modern''. -.[ -paul vixie edginess nmh-workers -.] -.P -Modern features that are active in mmh by default include: +In mmh, all modern features are active by default and many previous +approaches are removed or only accessible in manual ways. +New default features include: .BU The attachment system (\c .Hd Attach ). @@ -2757,6 +2750,14 @@ .BU Forwarding messages using MIME. .Ci 6e271608b7b9c23771523f88d23a4d3593010cf1 +.P +In consequence, a setup with a profile that defines only the path to the +mail storage, is already convenient to use. +Again, Paul Vixie's ``edginess'' appeal supports the direction I took: +``the `main branch' should just be modern''. +.[ +paul vixie edginess nmh-workers +.] @@ -2818,7 +2819,7 @@ (2) Any other whitespace should consist of spaces. These two rules ensure the integrity of the visual appearance. Although reformatting existing code should be avoided, I did it. -I did not waste time arguing; I just did it. +I did not waste time arguing; I just reformated the code. .Ci a485ed478abbd599d8c9aab48934e7a26733ecb1 .U3 "Comments @@ -2848,7 +2849,8 @@ VE .Ci 426543622b377fc5d091455cba685e114b6df674 .P -The names of the functions explain enough already. +The program code explains enough itself, already. + .U3 "Names .P @@ -2919,14 +2921,19 @@ .H2 "Structural Rework .P - -.U3 "Rework of \f(CWanno\fP +Although the stylistic changes described up to here improve the +readability of the source code, all of them are changes ``in the small''. +Structural changes affect a much larger area. +They are more difficult to do but lead to larger improvements, +especially as they influence the outer shape of the tools as well. .P At the end of their chapter on style, Kernighan and Pike ask: ``But why worry about style?'' -The following example of my rework of -.Pn anno -provides an answer why style is important in the first place. +Following are two examples of structural rework that show +why style is important in the first place. + + +.U3 "Rework of \f(CWanno\fP .P Until 2002, .Pn anno