--- a/discussion.roff	Sat Jun 30 15:07:35 2012 +0200
+++ b/discussion.roff	Sat Jun 30 16:50:35 2012 +0200
@@ -3261,109 +3261,97 @@
 
 
 
-.H2 "Separation
-
-.U3 "MH Directory Split
+.H2 "User Data Locations
 .P
-In MH and nmh, a personal setup had consisted of two parts:
-The MH profile, named
+In nmh, a personal setup consists of the MH profile and the MH directory.
+The profile is a file named
 .Fn \&.mh_profile
-and being located directly in the user's home directory.
-And the MH directory, where all his mail messages and also his personal
-forms, scan formats, other configuration files are stored.
-The location
-of this directory could be user-chosen.
-The default was to name it
+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
-and have it directly in the home directory.
+in the home directory.
 .P
-I've never liked the data storage and the configuration to be intermixed.
-They are different kinds of data.
-One part, are the messages,
-which are the data to operate on.
-The other part, are the personal
-configuration files, which are able to change the behavior of the operations.
-The actual operations are defined in the profile, however.
+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
-When storing data, one should try to group data by its type.
-There's sense in the Unix file system hierarchy, where configuration
-file are stored separate (\c
-.Fn /etc )
-to the programs (\c
-.Fn /bin
-and
-.Fn /usr/bin )
-to their sources (\c
-.Fn /usr/src ).
-Such separation eases the backup management, for instance.
-.P
-In mmh, I've reorganized the file locations.
-Still there are two places:
-There's the mail storage directory, which, like in MH, contains all the
-messages, but, unlike in MH, nothing else.
-Its location still is user-chosen, with the default name
+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.
-This is much similar to the case in nmh.
-The configuration files, however, are grouped together in the new directory
+In mmh, the configuration is grouped together in
+the hidden directory
 .Fn \&.mmh
 in the user's home directory.
-The user's profile now is a file, named
-.Fn profile ,
-in this mmh directory.
-Consistently, the context file and all the personal forms, scan formats,
-and the like, are also there.
-.P
-The naming changed with the relocation.
-The directory where everything, except the profile, had been stored (\c
-.Fn $HOME/Mail ),
-used to be called \fIMH directory\fP.
-Now, this directory is called the
-user's \fImail storage\fP.
-The name \fImmh directory\fP is now given to
-the new directory
-(\c
-.Fn $HOME/.mmh ),
-containing all the personal configuration files.
+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
-The separation of the files by type of content is logical and convenient.
-There are no functional differences as any possible setup known to me
-can be implemented with both approaches, although likely a bit easier
-with the new approach.
-The main goal of the change had been to provide
-sensible storage locations for any type of personal mmh file.
-.P
-In order for one user to have multiple MH setups, he can use the
-environment variable
+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
-the point to a different profile file.
-The MH directory (mail storage plus personal configuration files) is
-defined by the
-.Pe Path
-profile entry.
-The context file could be defined by the
-.Pe context
-profile entry or by the
+could be used to specifiy a different profile.
+To operate in the same MH setup with a separate context,
+the
 .Ev MHCONTEXT
-environment variable.
-The latter is useful to have a distinct context (e.g. current folders)
-in each terminal window, for instance.
-In mmh, there are three environment variables now.
+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
-may be used to change the location of the mmh directory.
+overrides the default location of the mmh directory (\c
+.Fn .mmh ).
 .Ev MMHP
 and
 .Ev MMHC
-change the profile and context files, respectively.
-Besides providing a more consistent feel (which simply is the result
-of being designed anew), the set of personal configuration files can
-be chosen independently from the profile (including mail storage location)
-and context, now.
-Being it relevant for practical use or not, it
-de-facto is an improvement.
-However, the main achievement is the
-split between mail storage and personal configuration files.
-
+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.