1.1 --- a/discussion.roff	Tue Jul 03 11:28:45 2012 +0200
     1.2 +++ b/discussion.roff	Tue Jul 03 16:50:41 2012 +0200
     1.3 @@ -11,6 +11,7 @@
     1.4  
     1.5  
     1.6  
     1.7 +.\" --------------------------------------------------------------
     1.8  .H1 "Streamlining
     1.9  
    1.10  .P
    1.11 @@ -424,48 +425,10 @@
    1.12  is unrelated to the rest of the project.
    1.13  
    1.14  
    1.15 -.H3 "Profile Reading
    1.16 +
    1.17 +.H2 "\fLshow\fP and \fPmhshow\fP
    1.18  .P
    1.19 -FIXME XXX
    1.20 -
    1.21 -commit 3e017a7abbdf69bf0dff7a4073275961eda1ded8
    1.22 -Author: markus schnalke <meillo@marmaro.de>
    1.23 -Date:   Wed Jun 27 14:23:35 2012 +0200
    1.24 -
    1.25 -    spost: Read profile and context now. Removed -library switch.
    1.26 -    spost is a full part of the mmh toolchest, hence, it shall read the
    1.27 -    profile/context. This will remove the need to pass profile information
    1.28 -    from send to spost via command line switches.
    1.29 -    In January 2012, there had been a discussion on the nmh-workers ML
    1.30 -    whether post should read the profile/context. There wasn't a clear
    1.31 -    answer. It behavior was mainly motivated by the historic situation,
    1.32 -    it seems. My opinion on the topic goes into the direction that every
    1.33 -    tool that is part of the mmh toolchest should read the profile. That
    1.34 -    is a clear and simple concept. Using MH tools without wanting to
    1.35 -    interact with MH (like mhmail had been) is no more a practical problem.
    1.36 -
    1.37 -commit 32d4f9daaa70519be3072479232ff7be0500d009
    1.38 -Author: markus schnalke <meillo@marmaro.de>
    1.39 -Date:   Wed Jun 27 13:15:47 2012 +0200
    1.40 -
    1.41 -    mhmail: Read the context!
    1.42 -    mhmail will change from a mailx-replacment to an alternative to
    1.43 -    `comp -ed prompter', thus being a send front-end. Hence, mhmail
    1.44 -    should not stay outside the profile/context respecting mmh toolchest.
    1.45 -
    1.46 -
    1.47 -slocal
    1.48 -
    1.49 -
    1.50 -
    1.51 -
    1.52 -.H2 "Displaying Messages
    1.53 -.P
    1.54 -FIXME XXX
    1.55 -
    1.56 -.U3 "\fLshow\fP and \fPmhshow\fP
    1.57 -.P
    1.58 -Since the very beginning \(en already in the first concept paper \(en
    1.59 +Since the very beginning, already in the first concept paper,
    1.60  .Pn show
    1.61  had been MH's message display program.
    1.62  .Pn show
    1.63 @@ -602,12 +565,11 @@
    1.64  supporting MIME demands for higher essential complexity.
    1.65  
    1.66  
    1.67 -.U3 "Scan Listings
    1.68 +.H2 "Scan Listings
    1.69  .P
    1.70  FIXME XXX
    1.71  
    1.72  .P
    1.73 -
    1.74  commit c20e315f9fb9f0f0955749726dbf4fd897cd9f48
    1.75  Author: markus schnalke <meillo@marmaro.de>
    1.76  Date:   Fri Dec 9 21:56:44 2011 +0100
    1.77 @@ -628,6 +590,7 @@
    1.78  
    1.79  
    1.80  
    1.81 +
    1.82  .H2 "Configure Options
    1.83  .P
    1.84  Customization is a double-edged sword.
    1.85 @@ -737,9 +700,8 @@
    1.86  .Cf "Sec. XXX
    1.87  obsoleted the concept of the backup prefix completely.
    1.88  .Ci 8edc5aaf86f9f77124664f6801bc6c6cdf258173
    1.89 -.\" (Well, there still are corner-cases to remove until the backup
    1.90 -.\" prefix can be laid to rest, eventually.)
    1.91 -.\" FIXME: Do this work in the code!
    1.92 +.Ci ca0b3e830b86700d9e5e31b1784de2bdcaf58fc5
    1.93 +
    1.94  
    1.95  .U3 "Editor and Pager
    1.96  .P
    1.97 @@ -1701,6 +1663,7 @@
    1.98  
    1.99  
   1.100  
   1.101 +.\" --------------------------------------------------------------
   1.102  .H1 "Modernizing
   1.103  .P
   1.104  In the over thirty years of MH's existence, its code base was
   1.105 @@ -2447,99 +2410,7 @@
   1.106  
   1.107  
   1.108  
   1.109 -.H2 "Modern Defaults
   1.110 -.P
   1.111 -Nmh has a bunch of convenience-improving features inactive by default,
   1.112 -although one can expect every new user wanting to have them active.
   1.113 -The reason they are inactive by default is the wish to stay compatible
   1.114 -with old versions.
   1.115 -But what is the definition for old versions.
   1.116 -Still, the highly useful draft folder facility is not active by default
   1.117 -although it had been introduced over twenty-five years ago
   1.118 -.[
   1.119 -rose romine real work
   1.120 -.]
   1.121 -\(en the community seems not to care.
   1.122 -This is one of several examples that require new users to build up
   1.123 -their profile before they can access the modern features of nmh.
   1.124 -Without an extensively built-up profile, the setup is hardly usable
   1.125 -for modern emailing.
   1.126 -The point is not the customization of the setup,
   1.127 -but the activating of generally useful facilities.
   1.128 -.P
   1.129 -Yet, the real problem lies less in enabling the features, as this is
   1.130 -straight forward as soon as one knows what he wants.
   1.131 -The real problem is that new users need deep insights into the project
   1.132 -before they find out what they are missing and that nmh actually
   1.133 -provides it already, it just was not activated.
   1.134 -To give an example, I needed one year of using nmh
   1.135 -before I became aware of the existence of the attachment system.
   1.136 -One could argue that this fact disqualifies my reading of the
   1.137 -documentation.
   1.138 -If I would have installed nmh from source back then, I could agree.
   1.139 -Yet, I had used a prepackaged version and had expected that it would
   1.140 -just work.
   1.141 -Nevertheless, I had been convinced by the concepts of MH already
   1.142 -and I am a software developer,
   1.143 -still I required a lot of time to discover the cool features.
   1.144 -How can we expect users to be even more advanced than me,
   1.145 -just to allow them use MH in a convenient and modern way?
   1.146 -Unless they are strongly convinced of the concepts, they will fail.
   1.147 -I have seen friends of me giving up disappointed
   1.148 -before they truly used the system,
   1.149 -although they had been motivated in the beginning.
   1.150 -They suffer hard enough to get used to the toolchest approach,
   1.151 -we should spare them further inconveniences.
   1.152 -.P
   1.153 -Maintaining compatibility for its own sake is for no good.
   1.154 -If any MH implementation would be the back-end of widespread
   1.155 -email clients with large user bases, compatibility would be more
   1.156 -important.
   1.157 -Yet, it appears as if this is not the case.
   1.158 -Hence, compatibility is hardly important for technical reasons.
   1.159 -Its importance originates rather from personal reasons.
   1.160 -Nmh's user base is small and old.
   1.161 -Changing the interfaces would cause inconvenience to long-term users of MH.
   1.162 -It would force them to change their many years old MH configurations.
   1.163 -I do understand this aspect, but it keeps new users from using MH.
   1.164 -By sticking to the old users, new users are kept away.
   1.165 -Yet, the future lies in new users.
   1.166 -Hence, mmh invites new users by providing a convenient and modern setup,
   1.167 -readily usable out-of-the-box.
   1.168 -.P
   1.169 -In mmh, all modern features are active by default.
   1.170 -In consequence, a setup with a profile that defines only the path to the
   1.171 -mail storage, is already convenient to use.
   1.172 -Again, Paul Vixie's ``edginess'' appeal supports the direction I took:
   1.173 -``the `main branch' should just be modern''.
   1.174 -.[
   1.175 -paul vixie edginess nmh-workers
   1.176 -.]
   1.177 -.P
   1.178 -Modern features that are active in mmh by default include: 
   1.179 -.BU
   1.180 -The attachment system (\c
   1.181 -.Hd Attach ).
   1.182 -.Ci 8ff284ff9167eff8f5349481529332d59ed913b1
   1.183 -.BU
   1.184 -The draft folder facility (\c
   1.185 -.Fn +drafts ).
   1.186 -.Ci 337338b404931f06f0db2119c9e145e8ca5a9860
   1.187 -.BU
   1.188 -The unseen sequence (`u')
   1.189 -.Ci c2360569e1d8d3678e294eb7c1354cb8bf7501c1
   1.190 -and the sequence negation prefix (`!').
   1.191 -.Ci db74c2bd004b2dc9bf8086a6d8bf773ac051f3cc
   1.192 -.BU
   1.193 -Quoting the original message in the reply.
   1.194 -.Ci 67411b1f95d6ec987b4c732459e1ba8a8ac192c6
   1.195 -.BU
   1.196 -Forwarding messages using MIME.
   1.197 -.Ci 6e271608b7b9c23771523f88d23a4d3593010cf1
   1.198 -
   1.199 -
   1.200 -
   1.201 -.H2 "Drafts and Trash Folder
   1.202 +.H2 "Draft and Trash Folder
   1.203  .P
   1.204  
   1.205  .U3 "Draft Folder
   1.206 @@ -2644,12 +2515,13 @@
   1.207  This simplified the source code of the tools, as well as the concepts.
   1.208  In mmh, draft management does not break with the MH concepts
   1.209  but applies them.
   1.210 +.Cl "scan +drafts" ,
   1.211 +for instance, is a truly natural request.
   1.212  Most of the work was already done by Rose in the eighties.
   1.213 -The original improvement in mmh is dropping the draft message approach
   1.214 -completely and thus simplifying the tools, the documentation and the
   1.215 -system as a whole.
   1.216 +The original improvement of mmh is dropping the old draft message approach
   1.217 +and thus simplifying the tools, the documentation and the system as a whole.
   1.218  Although my part in the draft handling improvement was small,
   1.219 -it was important.
   1.220 +it was an important one.
   1.221  
   1.222  
   1.223  .U3 "Trash Folder
   1.224 @@ -2807,7 +2679,101 @@
   1.225  
   1.226  
   1.227  
   1.228 +.H2 "Modern Defaults
   1.229 +.P
   1.230 +Nmh has a bunch of convenience-improving features inactive by default,
   1.231 +although one can expect every new user wanting to have them active.
   1.232 +The reason they are inactive by default is the wish to stay compatible
   1.233 +with old versions.
   1.234 +But what is the definition for old versions.
   1.235 +Still, the highly useful draft folder facility is not active by default
   1.236 +although it had been introduced over twenty-five years ago
   1.237 +.[
   1.238 +rose romine real work
   1.239 +.]
   1.240 +\(en the community seems not to care.
   1.241 +This is one of several examples that require new users to build up
   1.242 +their profile before they can access the modern features of nmh.
   1.243 +Without an extensively built-up profile, the setup is hardly usable
   1.244 +for modern emailing.
   1.245 +The point is not the customization of the setup,
   1.246 +but the activating of generally useful facilities.
   1.247 +.P
   1.248 +Yet, the real problem lies less in enabling the features, as this is
   1.249 +straight forward as soon as one knows what he wants.
   1.250 +The real problem is that new users need deep insights into the project
   1.251 +before they find out what they are missing and that nmh actually
   1.252 +provides it already, it just was not activated.
   1.253 +To give an example, I needed one year of using nmh
   1.254 +before I became aware of the existence of the attachment system.
   1.255 +One could argue that this fact disqualifies my reading of the
   1.256 +documentation.
   1.257 +If I would have installed nmh from source back then, I could agree.
   1.258 +Yet, I had used a prepackaged version and had expected that it would
   1.259 +just work.
   1.260 +Nevertheless, I had been convinced by the concepts of MH already
   1.261 +and I am a software developer,
   1.262 +still I required a lot of time to discover the cool features.
   1.263 +How can we expect users to be even more advanced than me,
   1.264 +just to allow them use MH in a convenient and modern way?
   1.265 +Unless they are strongly convinced of the concepts, they will fail.
   1.266 +I have seen friends of me giving up disappointed
   1.267 +before they truly used the system,
   1.268 +although they had been motivated in the beginning.
   1.269 +They suffer hard enough to get used to the toolchest approach,
   1.270 +we should spare them further inconveniences.
   1.271 +.P
   1.272 +Maintaining compatibility for its own sake is for no good.
   1.273 +If any MH implementation would be the back-end of widespread
   1.274 +email clients with large user bases, compatibility would be more
   1.275 +important.
   1.276 +Yet, it appears as if this is not the case.
   1.277 +Hence, compatibility is hardly important for technical reasons.
   1.278 +Its importance originates rather from personal reasons.
   1.279 +Nmh's user base is small and old.
   1.280 +Changing the interfaces would cause inconvenience to long-term users of MH.
   1.281 +It would force them to change their many years old MH configurations.
   1.282 +I do understand this aspect, but it keeps new users from using MH.
   1.283 +By sticking to the old users, new users are kept away.
   1.284 +Yet, the future lies in new users.
   1.285 +Hence, mmh invites new users by providing a convenient and modern setup,
   1.286 +readily usable out-of-the-box.
   1.287 +.P
   1.288 +In mmh, all modern features are active by default.
   1.289 +In consequence, a setup with a profile that defines only the path to the
   1.290 +mail storage, is already convenient to use.
   1.291 +Again, Paul Vixie's ``edginess'' appeal supports the direction I took:
   1.292 +``the `main branch' should just be modern''.
   1.293 +.[
   1.294 +paul vixie edginess nmh-workers
   1.295 +.]
   1.296 +.P
   1.297 +Modern features that are active in mmh by default include: 
   1.298 +.BU
   1.299 +The attachment system (\c
   1.300 +.Hd Attach ).
   1.301 +.Ci 8ff284ff9167eff8f5349481529332d59ed913b1
   1.302 +.BU
   1.303 +The draft folder facility (\c
   1.304 +.Fn +drafts ).
   1.305 +.Ci 337338b404931f06f0db2119c9e145e8ca5a9860
   1.306 +.BU
   1.307 +The unseen sequence (`u')
   1.308 +.Ci c2360569e1d8d3678e294eb7c1354cb8bf7501c1
   1.309 +and the sequence negation prefix (`!').
   1.310 +.Ci db74c2bd004b2dc9bf8086a6d8bf773ac051f3cc
   1.311 +.BU
   1.312 +Quoting the original message in the reply.
   1.313 +.Ci 67411b1f95d6ec987b4c732459e1ba8a8ac192c6
   1.314 +.BU
   1.315 +Forwarding messages using MIME.
   1.316 +.Ci 6e271608b7b9c23771523f88d23a4d3593010cf1
   1.317  
   1.318 +
   1.319 +
   1.320 +
   1.321 +
   1.322 +.\" --------------------------------------------------------------
   1.323  .H1 "Styling
   1.324  .P
   1.325  Kernighan and Pike have emphasized the importance of style in the
   1.326 @@ -2960,6 +2926,11 @@
   1.327  the possibility to improve had not be seen.
   1.328  .Ci aa60b0ab5e804f8befa890c0a6df0e3143ce0723
   1.329  
   1.330 +
   1.331 +
   1.332 +.H2 "Structural Rework
   1.333 +.P
   1.334 +
   1.335  .U3 "Rework of \f(CWanno\fP
   1.336  .P
   1.337  At the end of their chapter on style,
   1.338 @@ -3135,6 +3106,65 @@
   1.339  
   1.340  
   1.341  
   1.342 +.U3 "Path Conversion
   1.343 +.P
   1.344 +FIXME! XXX
   1.345 +
   1.346 +
   1.347 +commit d39e2c447b0d163a5a63f480b23d06edb7a73aa0
   1.348 +Author: markus schnalke <meillo@marmaro.de>
   1.349 +Date:   Fri Dec 9 16:34:57 2011 +0100
   1.350 +
   1.351 +    Completely reworked the path convertion functions
   1.352 +    Moved everything (from sbr/getfolder.c and sbr/m_maildir.c) into
   1.353 +    sbr/path.c, but actually replaced the code almost completely.
   1.354 +    See h/prototypes.h for the function changes.
   1.355 +    sbr/path.c provides explaining comments on the functions.
   1.356 +    None of them allocates memory automatically.
   1.357 +    
   1.358 +    Additionally:
   1.359 +    - Like for other ``files'', `inc -audit file' places file relative
   1.360 +      to the cwd, not relative to the mh-dir. This is for consistency.
   1.361 +    - Replaced add(foo, NULL) with getcpy(foo), which ist clearer.
   1.362 +
   1.363 +
   1.364 +
   1.365 +
   1.366 +
   1.367 +.H2 "Profile Reading
   1.368 +.P
   1.369 +FIXME XXX
   1.370 +
   1.371 +commit 3e017a7abbdf69bf0dff7a4073275961eda1ded8
   1.372 +Author: markus schnalke <meillo@marmaro.de>
   1.373 +Date:   Wed Jun 27 14:23:35 2012 +0200
   1.374 +
   1.375 +    spost: Read profile and context now. Removed -library switch.
   1.376 +    spost is a full part of the mmh toolchest, hence, it shall read the
   1.377 +    profile/context. This will remove the need to pass profile information
   1.378 +    from send to spost via command line switches.
   1.379 +    In January 2012, there had been a discussion on the nmh-workers ML
   1.380 +    whether post should read the profile/context. There wasn't a clear
   1.381 +    answer. It behavior was mainly motivated by the historic situation,
   1.382 +    it seems. My opinion on the topic goes into the direction that every
   1.383 +    tool that is part of the mmh toolchest should read the profile. That
   1.384 +    is a clear and simple concept. Using MH tools without wanting to
   1.385 +    interact with MH (like mhmail had been) is no more a practical problem.
   1.386 +
   1.387 +commit 32d4f9daaa70519be3072479232ff7be0500d009
   1.388 +Author: markus schnalke <meillo@marmaro.de>
   1.389 +Date:   Wed Jun 27 13:15:47 2012 +0200
   1.390 +
   1.391 +    mhmail: Read the context!
   1.392 +    mhmail will change from a mailx-replacment to an alternative to
   1.393 +    `comp -ed prompter', thus being a send front-end. Hence, mhmail
   1.394 +    should not stay outside the profile/context respecting mmh toolchest.
   1.395 +
   1.396 +
   1.397 +slocal
   1.398 +
   1.399 +
   1.400 +
   1.401  
   1.402  .H2 "Standard Libraries
   1.403  .P
   1.404 @@ -3304,6 +3334,103 @@
   1.405  
   1.406  
   1.407  
   1.408 +
   1.409 +.H2 "User Data Locations
   1.410 +.P
   1.411 +In nmh, a personal setup consists of the MH profile and the MH directory.
   1.412 +The profile is a file named
   1.413 +.Fn \&.mh_profile
   1.414 +in the user's home directory.
   1.415 +It contains the static configuration.
   1.416 +It also contains the location of the MH directory in the profile entry
   1.417 +.Pe Path .
   1.418 +The MH directory contains the mail storage and is the first
   1.419 +place to search for personal forms, scan formats, and similar
   1.420 +configuration files.
   1.421 +The location of the MH directory can be chosen freely by the user.
   1.422 +The default and usual name is a directory named
   1.423 +.Fn Mail
   1.424 +in the home directory.
   1.425 +.P
   1.426 +The way MH data is splitted between profile and MH directory is a legacy.
   1.427 +It is only sensible in a situation where the profile is the only
   1.428 +configuration file.
   1.429 +Why else should the mail storage and the configuration files be intermixed?
   1.430 +They are different kinds of data:
   1.431 +The data to be operated on and the configuration to change how
   1.432 +tools operate.
   1.433 +Splitting the configuration between the profile and the MH directory
   1.434 +is bad.
   1.435 +Merging the mail storage and the configuration in one directory is bad
   1.436 +as well.
   1.437 +As the mail storage and the configuration were not separated sensibly
   1.438 +in the first place, I did it now.
   1.439 +.P
   1.440 +Personal mmh data is grouped by type, resulting in two distinct parts:
   1.441 +The mail storage and the configuration.
   1.442 +In mmh, the mail storage directory still contains all the messages,
   1.443 +but, in exception of public sequences files, nothing else.
   1.444 +In difference to nmh, the auxiliary configuration files are no longer
   1.445 +located there.
   1.446 +Therefore, the directory is no longer called the user's \fIMH directory\fP
   1.447 +but his \fImail storage\fP.
   1.448 +Its location is still user-chosen, with the default name
   1.449 +.Fn Mail ,
   1.450 +in the user's home directory.
   1.451 +In mmh, the configuration is grouped together in
   1.452 +the hidden directory
   1.453 +.Fn \&.mmh
   1.454 +in the user's home directory.
   1.455 +This \fImmh directory\fP contains the context file, personal forms,
   1.456 +scan formats, and the like, but also the user's profile, now named
   1.457 +.Fn profile .
   1.458 +The location of the profile is no longer fixed to
   1.459 +.Fn $HOME/.mh_profile
   1.460 +but to
   1.461 +.Fn $HOME/.mmh/profile .
   1.462 +Having both, the file
   1.463 +.Fn $HOME/.mh_profile
   1.464 +and the configuration directory
   1.465 +.Fn $HOME/.mmh
   1.466 +appeared to be inconsistent.
   1.467 +The approach chosen for mmh is consistent, simple, and familiar to
   1.468 +Unix users.
   1.469 +.P
   1.470 +MH allows users to have multiiple MH setups.
   1.471 +Therefore, it is necessary to select a different profile.
   1.472 +The profile is the single entry point to access the rest of a
   1.473 +personal MH setup.
   1.474 +In nmh, the environment variable
   1.475 +.Ev MH
   1.476 +could be used to specifiy a different profile.
   1.477 +To operate in the same MH setup with a separate context,
   1.478 +the
   1.479 +.Ev MHCONTEXT
   1.480 +environment variable could be used.
   1.481 +This allows having own current folders and current messages in
   1.482 +each terminal, for instance.
   1.483 +In mmh, three environment variables are used.
   1.484 +.Ev MMH
   1.485 +overrides the default location of the mmh directory (\c
   1.486 +.Fn .mmh ).
   1.487 +.Ev MMHP
   1.488 +and
   1.489 +.Ev MMHC
   1.490 +override the paths to the profile and context files, respectively.
   1.491 +This approach allows the set of personal configuration files to be chosen
   1.492 +independently from the profile, context, and mail storage.
   1.493 +.P
   1.494 +The separation of the files by type is sensible and convenient.
   1.495 +The new approach has no functional disadvantages,
   1.496 +as every setup I can imagine can be implemented with both approaches,
   1.497 +possibly even easier with the new approach.
   1.498 +The main achievement of the change is the clear and sensible split
   1.499 +between mail storage and configuration.
   1.500 +
   1.501 +
   1.502 +
   1.503 +
   1.504 +
   1.505  .H2 "Modularization
   1.506  .P
   1.507  The source code of the mmh tools is located in the
   1.508 @@ -3592,121 +3719,3 @@
   1.509  Installing regression tests is a task left to do.
   1.510  In the best case, a uniform way of invoking tools from other tools
   1.511  can be developed to allow automated testing at compile time.
   1.512 -
   1.513 -
   1.514 -
   1.515 -
   1.516 -.H2 "User Data Locations
   1.517 -.P
   1.518 -In nmh, a personal setup consists of the MH profile and the MH directory.
   1.519 -The profile is a file named
   1.520 -.Fn \&.mh_profile
   1.521 -in the user's home directory.
   1.522 -It contains the static configuration.
   1.523 -It also contains the location of the MH directory in the profile entry
   1.524 -.Pe Path .
   1.525 -The MH directory contains the mail storage and is the first
   1.526 -place to search for personal forms, scan formats, and similar
   1.527 -configuration files.
   1.528 -The location of the MH directory can be chosen freely by the user.
   1.529 -The default and usual name is a directory named
   1.530 -.Fn Mail
   1.531 -in the home directory.
   1.532 -.P
   1.533 -The way MH data is splitted between profile and MH directory is a legacy.
   1.534 -It is only sensible in a situation where the profile is the only
   1.535 -configuration file.
   1.536 -Why else should the mail storage and the configuration files be intermixed?
   1.537 -They are different kinds of data:
   1.538 -The data to be operated on and the configuration to change how
   1.539 -tools operate.
   1.540 -Splitting the configuration between the profile and the MH directory
   1.541 -is bad.
   1.542 -Merging the mail storage and the configuration in one directory is bad
   1.543 -as well.
   1.544 -As the mail storage and the configuration were not separated sensibly
   1.545 -in the first place, I did it now.
   1.546 -.P
   1.547 -Personal mmh data is grouped by type, resulting in two distinct parts:
   1.548 -The mail storage and the configuration.
   1.549 -In mmh, the mail storage directory still contains all the messages,
   1.550 -but, in exception of public sequences files, nothing else.
   1.551 -In difference to nmh, the auxiliary configuration files are no longer
   1.552 -located there.
   1.553 -Therefore, the directory is no longer called the user's \fIMH directory\fP
   1.554 -but his \fImail storage\fP.
   1.555 -Its location is still user-chosen, with the default name
   1.556 -.Fn Mail ,
   1.557 -in the user's home directory.
   1.558 -In mmh, the configuration is grouped together in
   1.559 -the hidden directory
   1.560 -.Fn \&.mmh
   1.561 -in the user's home directory.
   1.562 -This \fImmh directory\fP contains the context file, personal forms,
   1.563 -scan formats, and the like, but also the user's profile, now named
   1.564 -.Fn profile .
   1.565 -The location of the profile is no longer fixed to
   1.566 -.Fn $HOME/.mh_profile
   1.567 -but to
   1.568 -.Fn $HOME/.mmh/profile .
   1.569 -Having both, the file
   1.570 -.Fn $HOME/.mh_profile
   1.571 -and the configuration directory
   1.572 -.Fn $HOME/.mmh
   1.573 -appeared to be inconsistent.
   1.574 -The approach chosen for mmh is consistent, simple, and familiar to
   1.575 -Unix users.
   1.576 -.P
   1.577 -MH allows users to have multiiple MH setups.
   1.578 -Therefore, it is necessary to select a different profile.
   1.579 -The profile is the single entry point to access the rest of a
   1.580 -personal MH setup.
   1.581 -In nmh, the environment variable
   1.582 -.Ev MH
   1.583 -could be used to specifiy a different profile.
   1.584 -To operate in the same MH setup with a separate context,
   1.585 -the
   1.586 -.Ev MHCONTEXT
   1.587 -environment variable could be used.
   1.588 -This allows having own current folders and current messages in
   1.589 -each terminal, for instance.
   1.590 -In mmh, three environment variables are used.
   1.591 -.Ev MMH
   1.592 -overrides the default location of the mmh directory (\c
   1.593 -.Fn .mmh ).
   1.594 -.Ev MMHP
   1.595 -and
   1.596 -.Ev MMHC
   1.597 -override the paths to the profile and context files, respectively.
   1.598 -This approach allows the set of personal configuration files to be chosen
   1.599 -independently from the profile, context, and mail storage.
   1.600 -.P
   1.601 -The separation of the files by type is sensible and convenient.
   1.602 -The new approach has no functional disadvantages,
   1.603 -as every setup I can imagine can be implemented with both approaches,
   1.604 -possibly even easier with the new approach.
   1.605 -The main achievement of the change is the clear and sensible split
   1.606 -between mail storage and configuration.
   1.607 -
   1.608 -
   1.609 -
   1.610 -.H2 "Path Conversion
   1.611 -.P
   1.612 -FIXME! XXX
   1.613 -
   1.614 -
   1.615 -commit d39e2c447b0d163a5a63f480b23d06edb7a73aa0
   1.616 -Author: markus schnalke <meillo@marmaro.de>
   1.617 -Date:   Fri Dec 9 16:34:57 2011 +0100
   1.618 -
   1.619 -    Completely reworked the path convertion functions
   1.620 -    Moved everything (from sbr/getfolder.c and sbr/m_maildir.c) into
   1.621 -    sbr/path.c, but actually replaced the code almost completely.
   1.622 -    See h/prototypes.h for the function changes.
   1.623 -    sbr/path.c provides explaining comments on the functions.
   1.624 -    None of them allocates memory automatically.
   1.625 -    
   1.626 -    Additionally:
   1.627 -    - Like for other ``files'', `inc -audit file' places file relative
   1.628 -      to the cwd, not relative to the mh-dir. This is for consistency.
   1.629 -    - Replaced add(foo, NULL) with getcpy(foo), which ist clearer.