--- a/discussion.roff	Tue Jul 03 11:28:45 2012 +0200
+++ b/discussion.roff	Tue Jul 03 16:50:41 2012 +0200
@@ -11,6 +11,7 @@
 
 
 
+.\" --------------------------------------------------------------
 .H1 "Streamlining
 
 .P
@@ -424,48 +425,10 @@
 is unrelated to the rest of the project.
 
 
-.H3 "Profile Reading
+
+.H2 "\fLshow\fP and \fPmhshow\fP
 .P
-FIXME XXX
-
-commit 3e017a7abbdf69bf0dff7a4073275961eda1ded8
-Author: markus schnalke <meillo@marmaro.de>
-Date:   Wed Jun 27 14:23:35 2012 +0200
-
-    spost: Read profile and context now. Removed -library switch.
-    spost is a full part of the mmh toolchest, hence, it shall read the
-    profile/context. This will remove the need to pass profile information
-    from send to spost via command line switches.
-    In January 2012, there had been a discussion on the nmh-workers ML
-    whether post should read the profile/context. There wasn't a clear
-    answer. It behavior was mainly motivated by the historic situation,
-    it seems. My opinion on the topic goes into the direction that every
-    tool that is part of the mmh toolchest should read the profile. That
-    is a clear and simple concept. Using MH tools without wanting to
-    interact with MH (like mhmail had been) is no more a practical problem.
-
-commit 32d4f9daaa70519be3072479232ff7be0500d009
-Author: markus schnalke <meillo@marmaro.de>
-Date:   Wed Jun 27 13:15:47 2012 +0200
-
-    mhmail: Read the context!
-    mhmail will change from a mailx-replacment to an alternative to
-    `comp -ed prompter', thus being a send front-end. Hence, mhmail
-    should not stay outside the profile/context respecting mmh toolchest.
-
-
-slocal
-
-
-
-
-.H2 "Displaying Messages
-.P
-FIXME XXX
-
-.U3 "\fLshow\fP and \fPmhshow\fP
-.P
-Since the very beginning \(en already in the first concept paper \(en
+Since the very beginning, already in the first concept paper,
 .Pn show
 had been MH's message display program.
 .Pn show
@@ -602,12 +565,11 @@
 supporting MIME demands for higher essential complexity.
 
 
-.U3 "Scan Listings
+.H2 "Scan Listings
 .P
 FIXME XXX
 
 .P
-
 commit c20e315f9fb9f0f0955749726dbf4fd897cd9f48
 Author: markus schnalke <meillo@marmaro.de>
 Date:   Fri Dec 9 21:56:44 2011 +0100
@@ -628,6 +590,7 @@
 
 
 
+
 .H2 "Configure Options
 .P
 Customization is a double-edged sword.
@@ -737,9 +700,8 @@
 .Cf "Sec. XXX
 obsoleted the concept of the backup prefix completely.
 .Ci 8edc5aaf86f9f77124664f6801bc6c6cdf258173
-.\" (Well, there still are corner-cases to remove until the backup
-.\" prefix can be laid to rest, eventually.)
-.\" FIXME: Do this work in the code!
+.Ci ca0b3e830b86700d9e5e31b1784de2bdcaf58fc5
+
 
 .U3 "Editor and Pager
 .P
@@ -1701,6 +1663,7 @@
 
 
 
+.\" --------------------------------------------------------------
 .H1 "Modernizing
 .P
 In the over thirty years of MH's existence, its code base was
@@ -2447,99 +2410,7 @@
 
 
 
-.H2 "Modern Defaults
-.P
-Nmh has a bunch of convenience-improving features inactive by default,
-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
-.[
-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
-for modern emailing.
-The point is not the customization of the setup,
-but the activating of 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.
-The real problem is that new users need deep insights into the project
-before they find out what they are missing and that nmh actually
-provides it already, it just was not activated.
-To give an example, I needed one year of using nmh
-before I became aware of the existence of the attachment system.
-One could argue that this fact disqualifies my reading of the
-documentation.
-If I would have installed nmh from source back then, I could agree.
-Yet, I had used a prepackaged version and had expected that it would
-just work.
-Nevertheless, I had been convinced by the concepts of MH already
-and I am a software developer,
-still I required a lot of time to discover the cool features.
-How can we expect users to be even more advanced than me,
-just to allow them use MH in a convenient and modern way?
-Unless they are strongly convinced of the concepts, they will fail.
-I have seen friends of me giving up disappointed
-before they truly used the system,
-although they had been motivated in the beginning.
-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.
-If any MH implementation would be the back-end of widespread
-email clients with large user bases, compatibility would be more
-important.
-Yet, it appears as if this is not the case.
-Hence, compatibility is hardly important for technical reasons.
-Its importance originates rather from personal reasons.
-Nmh's user base is small and old.
-Changing the interfaces would cause inconvenience to long-term users of MH.
-It would force them to change their many years old MH configurations.
-I do understand this aspect, but it keeps new users from using MH.
-By sticking to the old users, new users are kept away.
-Yet, the future lies in new users.
-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: 
-.BU
-The attachment system (\c
-.Hd Attach ).
-.Ci 8ff284ff9167eff8f5349481529332d59ed913b1
-.BU
-The draft folder facility (\c
-.Fn +drafts ).
-.Ci 337338b404931f06f0db2119c9e145e8ca5a9860
-.BU
-The unseen sequence (`u')
-.Ci c2360569e1d8d3678e294eb7c1354cb8bf7501c1
-and the sequence negation prefix (`!').
-.Ci db74c2bd004b2dc9bf8086a6d8bf773ac051f3cc
-.BU
-Quoting the original message in the reply.
-.Ci 67411b1f95d6ec987b4c732459e1ba8a8ac192c6
-.BU
-Forwarding messages using MIME.
-.Ci 6e271608b7b9c23771523f88d23a4d3593010cf1
-
-
-
-.H2 "Drafts and Trash Folder
+.H2 "Draft and Trash Folder
 .P
 
 .U3 "Draft Folder
@@ -2644,12 +2515,13 @@
 This simplified the source code of the tools, as well as the concepts.
 In mmh, draft management does not break with the MH concepts
 but applies them.
+.Cl "scan +drafts" ,
+for instance, is a truly natural request.
 Most of the work was already done by Rose in the eighties.
-The original improvement in mmh is dropping the draft message approach
-completely and thus simplifying the tools, the documentation and the
-system as a whole.
+The original improvement of mmh is dropping the old draft message approach
+and thus simplifying the tools, the documentation and the system as a whole.
 Although my part in the draft handling improvement was small,
-it was important.
+it was an important one.
 
 
 .U3 "Trash Folder
@@ -2807,7 +2679,101 @@
 
 
 
+.H2 "Modern Defaults
+.P
+Nmh has a bunch of convenience-improving features inactive by default,
+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
+.[
+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
+for modern emailing.
+The point is not the customization of the setup,
+but the activating of 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.
+The real problem is that new users need deep insights into the project
+before they find out what they are missing and that nmh actually
+provides it already, it just was not activated.
+To give an example, I needed one year of using nmh
+before I became aware of the existence of the attachment system.
+One could argue that this fact disqualifies my reading of the
+documentation.
+If I would have installed nmh from source back then, I could agree.
+Yet, I had used a prepackaged version and had expected that it would
+just work.
+Nevertheless, I had been convinced by the concepts of MH already
+and I am a software developer,
+still I required a lot of time to discover the cool features.
+How can we expect users to be even more advanced than me,
+just to allow them use MH in a convenient and modern way?
+Unless they are strongly convinced of the concepts, they will fail.
+I have seen friends of me giving up disappointed
+before they truly used the system,
+although they had been motivated in the beginning.
+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.
+If any MH implementation would be the back-end of widespread
+email clients with large user bases, compatibility would be more
+important.
+Yet, it appears as if this is not the case.
+Hence, compatibility is hardly important for technical reasons.
+Its importance originates rather from personal reasons.
+Nmh's user base is small and old.
+Changing the interfaces would cause inconvenience to long-term users of MH.
+It would force them to change their many years old MH configurations.
+I do understand this aspect, but it keeps new users from using MH.
+By sticking to the old users, new users are kept away.
+Yet, the future lies in new users.
+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: 
+.BU
+The attachment system (\c
+.Hd Attach ).
+.Ci 8ff284ff9167eff8f5349481529332d59ed913b1
+.BU
+The draft folder facility (\c
+.Fn +drafts ).
+.Ci 337338b404931f06f0db2119c9e145e8ca5a9860
+.BU
+The unseen sequence (`u')
+.Ci c2360569e1d8d3678e294eb7c1354cb8bf7501c1
+and the sequence negation prefix (`!').
+.Ci db74c2bd004b2dc9bf8086a6d8bf773ac051f3cc
+.BU
+Quoting the original message in the reply.
+.Ci 67411b1f95d6ec987b4c732459e1ba8a8ac192c6
+.BU
+Forwarding messages using MIME.
+.Ci 6e271608b7b9c23771523f88d23a4d3593010cf1
 
+
+
+
+
+.\" --------------------------------------------------------------
 .H1 "Styling
 .P
 Kernighan and Pike have emphasized the importance of style in the
@@ -2960,6 +2926,11 @@
 the possibility to improve had not be seen.
 .Ci aa60b0ab5e804f8befa890c0a6df0e3143ce0723
 
+
+
+.H2 "Structural Rework
+.P
+
 .U3 "Rework of \f(CWanno\fP
 .P
 At the end of their chapter on style,
@@ -3135,6 +3106,65 @@
 
 
 
+.U3 "Path Conversion
+.P
+FIXME! XXX
+
+
+commit d39e2c447b0d163a5a63f480b23d06edb7a73aa0
+Author: markus schnalke <meillo@marmaro.de>
+Date:   Fri Dec 9 16:34:57 2011 +0100
+
+    Completely reworked the path convertion functions
+    Moved everything (from sbr/getfolder.c and sbr/m_maildir.c) into
+    sbr/path.c, but actually replaced the code almost completely.
+    See h/prototypes.h for the function changes.
+    sbr/path.c provides explaining comments on the functions.
+    None of them allocates memory automatically.
+    
+    Additionally:
+    - Like for other ``files'', `inc -audit file' places file relative
+      to the cwd, not relative to the mh-dir. This is for consistency.
+    - Replaced add(foo, NULL) with getcpy(foo), which ist clearer.
+
+
+
+
+
+.H2 "Profile Reading
+.P
+FIXME XXX
+
+commit 3e017a7abbdf69bf0dff7a4073275961eda1ded8
+Author: markus schnalke <meillo@marmaro.de>
+Date:   Wed Jun 27 14:23:35 2012 +0200
+
+    spost: Read profile and context now. Removed -library switch.
+    spost is a full part of the mmh toolchest, hence, it shall read the
+    profile/context. This will remove the need to pass profile information
+    from send to spost via command line switches.
+    In January 2012, there had been a discussion on the nmh-workers ML
+    whether post should read the profile/context. There wasn't a clear
+    answer. It behavior was mainly motivated by the historic situation,
+    it seems. My opinion on the topic goes into the direction that every
+    tool that is part of the mmh toolchest should read the profile. That
+    is a clear and simple concept. Using MH tools without wanting to
+    interact with MH (like mhmail had been) is no more a practical problem.
+
+commit 32d4f9daaa70519be3072479232ff7be0500d009
+Author: markus schnalke <meillo@marmaro.de>
+Date:   Wed Jun 27 13:15:47 2012 +0200
+
+    mhmail: Read the context!
+    mhmail will change from a mailx-replacment to an alternative to
+    `comp -ed prompter', thus being a send front-end. Hence, mhmail
+    should not stay outside the profile/context respecting mmh toolchest.
+
+
+slocal
+
+
+
 
 .H2 "Standard Libraries
 .P
@@ -3304,6 +3334,103 @@
 
 
 
+
+.H2 "User Data Locations
+.P
+In nmh, a personal setup consists of the MH profile and the MH directory.
+The profile is a file named
+.Fn \&.mh_profile
+in the user's home directory.
+It contains the static configuration.
+It also contains the location of the MH directory in the profile entry
+.Pe Path .
+The MH directory contains the mail storage and is the first
+place to search for personal forms, scan formats, and similar
+configuration files.
+The location of the MH directory can be chosen freely by the user.
+The default and usual name is a directory named
+.Fn Mail
+in the home directory.
+.P
+The way MH data is splitted between profile and MH directory is a legacy.
+It is only sensible in a situation where the profile is the only
+configuration file.
+Why else should the mail storage and the configuration files be intermixed?
+They are different kinds of data:
+The data to be operated on and the configuration to change how
+tools operate.
+Splitting the configuration between the profile and the MH directory
+is bad.
+Merging the mail storage and the configuration in one directory is bad
+as well.
+As the mail storage and the configuration were not separated sensibly
+in the first place, I did it now.
+.P
+Personal mmh data is grouped by type, resulting in two distinct parts:
+The mail storage and the configuration.
+In mmh, the mail storage directory still contains all the messages,
+but, in exception of public sequences files, nothing else.
+In difference to nmh, the auxiliary configuration files are no longer
+located there.
+Therefore, the directory is no longer called the user's \fIMH directory\fP
+but his \fImail storage\fP.
+Its location is still user-chosen, with the default name
+.Fn Mail ,
+in the user's home directory.
+In mmh, the configuration is grouped together in
+the hidden directory
+.Fn \&.mmh
+in the user's home directory.
+This \fImmh directory\fP contains the context file, personal forms,
+scan formats, and the like, but also the user's profile, now named
+.Fn profile .
+The location of the profile is no longer fixed to
+.Fn $HOME/.mh_profile
+but to
+.Fn $HOME/.mmh/profile .
+Having both, the file
+.Fn $HOME/.mh_profile
+and the configuration directory
+.Fn $HOME/.mmh
+appeared to be inconsistent.
+The approach chosen for mmh is consistent, simple, and familiar to
+Unix users.
+.P
+MH allows users to have multiiple MH setups.
+Therefore, it is necessary to select a different profile.
+The profile is the single entry point to access the rest of a
+personal MH setup.
+In nmh, the environment variable
+.Ev MH
+could be used to specifiy a different profile.
+To operate in the same MH setup with a separate context,
+the
+.Ev MHCONTEXT
+environment variable could be used.
+This allows having own current folders and current messages in
+each terminal, for instance.
+In mmh, three environment variables are used.
+.Ev MMH
+overrides the default location of the mmh directory (\c
+.Fn .mmh ).
+.Ev MMHP
+and
+.Ev MMHC
+override the paths to the profile and context files, respectively.
+This approach allows the set of personal configuration files to be chosen
+independently from the profile, context, and mail storage.
+.P
+The separation of the files by type is sensible and convenient.
+The new approach has no functional disadvantages,
+as every setup I can imagine can be implemented with both approaches,
+possibly even easier with the new approach.
+The main achievement of the change is the clear and sensible split
+between mail storage and configuration.
+
+
+
+
+
 .H2 "Modularization
 .P
 The source code of the mmh tools is located in the
@@ -3592,121 +3719,3 @@
 Installing regression tests is a task left to do.
 In the best case, a uniform way of invoking tools from other tools
 can be developed to allow automated testing at compile time.
-
-
-
-
-.H2 "User Data Locations
-.P
-In nmh, a personal setup consists of the MH profile and the MH directory.
-The profile is a file named
-.Fn \&.mh_profile
-in the user's home directory.
-It contains the static configuration.
-It also contains the location of the MH directory in the profile entry
-.Pe Path .
-The MH directory contains the mail storage and is the first
-place to search for personal forms, scan formats, and similar
-configuration files.
-The location of the MH directory can be chosen freely by the user.
-The default and usual name is a directory named
-.Fn Mail
-in the home directory.
-.P
-The way MH data is splitted between profile and MH directory is a legacy.
-It is only sensible in a situation where the profile is the only
-configuration file.
-Why else should the mail storage and the configuration files be intermixed?
-They are different kinds of data:
-The data to be operated on and the configuration to change how
-tools operate.
-Splitting the configuration between the profile and the MH directory
-is bad.
-Merging the mail storage and the configuration in one directory is bad
-as well.
-As the mail storage and the configuration were not separated sensibly
-in the first place, I did it now.
-.P
-Personal mmh data is grouped by type, resulting in two distinct parts:
-The mail storage and the configuration.
-In mmh, the mail storage directory still contains all the messages,
-but, in exception of public sequences files, nothing else.
-In difference to nmh, the auxiliary configuration files are no longer
-located there.
-Therefore, the directory is no longer called the user's \fIMH directory\fP
-but his \fImail storage\fP.
-Its location is still user-chosen, with the default name
-.Fn Mail ,
-in the user's home directory.
-In mmh, the configuration is grouped together in
-the hidden directory
-.Fn \&.mmh
-in the user's home directory.
-This \fImmh directory\fP contains the context file, personal forms,
-scan formats, and the like, but also the user's profile, now named
-.Fn profile .
-The location of the profile is no longer fixed to
-.Fn $HOME/.mh_profile
-but to
-.Fn $HOME/.mmh/profile .
-Having both, the file
-.Fn $HOME/.mh_profile
-and the configuration directory
-.Fn $HOME/.mmh
-appeared to be inconsistent.
-The approach chosen for mmh is consistent, simple, and familiar to
-Unix users.
-.P
-MH allows users to have multiiple MH setups.
-Therefore, it is necessary to select a different profile.
-The profile is the single entry point to access the rest of a
-personal MH setup.
-In nmh, the environment variable
-.Ev MH
-could be used to specifiy a different profile.
-To operate in the same MH setup with a separate context,
-the
-.Ev MHCONTEXT
-environment variable could be used.
-This allows having own current folders and current messages in
-each terminal, for instance.
-In mmh, three environment variables are used.
-.Ev MMH
-overrides the default location of the mmh directory (\c
-.Fn .mmh ).
-.Ev MMHP
-and
-.Ev MMHC
-override the paths to the profile and context files, respectively.
-This approach allows the set of personal configuration files to be chosen
-independently from the profile, context, and mail storage.
-.P
-The separation of the files by type is sensible and convenient.
-The new approach has no functional disadvantages,
-as every setup I can imagine can be implemented with both approaches,
-possibly even easier with the new approach.
-The main achievement of the change is the clear and sensible split
-between mail storage and configuration.
-
-
-
-.H2 "Path Conversion
-.P
-FIXME! XXX
-
-
-commit d39e2c447b0d163a5a63f480b23d06edb7a73aa0
-Author: markus schnalke <meillo@marmaro.de>
-Date:   Fri Dec 9 16:34:57 2011 +0100
-
-    Completely reworked the path convertion functions
-    Moved everything (from sbr/getfolder.c and sbr/m_maildir.c) into
-    sbr/path.c, but actually replaced the code almost completely.
-    See h/prototypes.h for the function changes.
-    sbr/path.c provides explaining comments on the functions.
-    None of them allocates memory automatically.
-    
-    Additionally:
-    - Like for other ``files'', `inc -audit file' places file relative
-      to the cwd, not relative to the mh-dir. This is for consistency.
-    - Replaced add(foo, NULL) with getcpy(foo), which ist clearer.