# HG changeset patch # User markus schnalke # Date 1341327041 -7200 # Node ID 02660c14f6a857f3cf3877f0cc6273c48c7fb001 # Parent 8c56dac46efef3a6114ecbeb3f4cd7afa44aff9b Further re-ordering of the sections. diff -r 8c56dac46efe -r 02660c14f6a8 discussion.roff --- 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 -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 -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 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 +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 +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 +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 -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.