# HG changeset patch # User markus schnalke # Date 1341306672 -7200 # Node ID 7c741bc8f7193c5fa5f40c4ed4072b05b9cea074 # Parent 0b9aa74ced4dfc11464c447848093e9403f0c7a7 Reorganized: Converted 4-parted discussion into 3-parted discussion. diff -r 0b9aa74ced4d -r 7c741bc8f719 discussion.roff --- a/discussion.roff Mon Jul 02 23:14:19 2012 +0200 +++ b/discussion.roff Tue Jul 03 11:11:12 2012 +0200 @@ -424,7 +424,46 @@ is unrelated to the rest of the project. -.H2 "\fLshow\fP and \fPmhshow\fP +.H3 "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 "Displaying Messages +.P +FIXME XXX + +.U3 "\fLshow\fP and \fPmhshow\fP .P Since the very beginning \(en already in the first concept paper \(en .Pn show @@ -563,6 +602,32 @@ supporting MIME demands for higher essential complexity. +.U3 "Scan Listings +.P +FIXME XXX + +.P + +commit c20e315f9fb9f0f0955749726dbf4fd897cd9f48 +Author: markus schnalke +Date: Fri Dec 9 21:56:44 2011 +0100 + + Adjusted the default scan listing: remove the body preview + The original listing is still available as etc/scan.nmh + +commit 70b2643e0da8485174480c644ad9785c84f5bff4 +Author: markus schnalke +Date: Mon Jan 30 16:16:26 2012 +0100 + + Scan listings shall not contain body content. Hence, removed this feature. + Scan listings shall operator on message headers and non-message information + only. Displaying the beginning of the body complicates everything too much. + That's no surprise, because it's something completely different. If you + want to examine the body, then use show(1)/mhshow(1). + Changed the default scan formats accordingly. + + + .H2 "Configure Options .P Customization is a double-edged sword. @@ -2474,8 +2539,276 @@ +.H2 "Drafts and Trash Folder +.P -.H1 "Style +.U3 "Draft Folder +.P +In the beginning, MH had the concept of a draft message. +This is the file +.Fn draft +in the MH directory, which is treated special. +On composing a message, this draft file was used. +As the draft file was one particular file, only one draft could be +managed at any time. +When starting to compose another message before the former one was sent, +the user had to decide among: +.BU +Use the old draft to finish and send it before starting with a new one. +.BU +Discard the old draft, replacing it with the new one. +.BU +Preserve the old draft by refiling it to a folder. +.P +This was, it was only possible to work in alternation on multiple drafts. +Therefore, the current draft needed to be refiled to a folder and +another one re-using for editing. +Working on multiple drafts at the same time was impossible. +The usual approach of switching to a different MH context did not +change anything. +.P +The draft folder facility exists to +allow true parallel editing of drafts, in a straight forward way. +It was introduced by Marshall T. Rose, already in 1984. +Similar to other new features, the draft folder was inactive by default. +Even in nmh, the highly useful draft folder was not available +out-of-the-box. +At least, Richard Coleman added the man page +.Mp mh-draft (5) +to better document the feature. +.P +Not using the draft folder facility has the single advantage of having +the draft file at a static location. +This is simple in simple cases but the concept does not scale for more +complex cases. +The concept of the draft message is too limited for the problem. +Therefore the draft folder was introduced. +It is the more powerful and more natural concept. +The draft folder is a folder like any other folder in MH. +Its messages can be listed like any other messages. +A draft message is no longer a special case. +Tools do not need special switches to work on the draft message. +Hence corner-cases were removed. +.P +The trivial part of the work was activating the draft folder with a +default name. +I chose the name +.Fn +drafts +for obvious reasons. +In consequence, the command line switches +.Sw -draftfolder +and +.Sw -draftmessage +could be removed. +More difficult but also more improving was updating the tools to the +new concept. +For nearly three decades, the tools needed to support two draft handling +approaches. +By fully switching to the draft folder, the tools could be simplified +by dropping the awkward draft message handling code. +.Sw -draft +switches were removed because operating on a draft message is no longer +special. +It became indistinguishable to operating on any other message. +There is no more need to query the user for draft handling. +It is always possible to add another new draft. +Refiling drafts is without difference to refiling other messages. +All these special cases are gone. +Yet, one draft-related switch remained. +.Pn comp +still has +.Sw -[no]use +for switching between two modes: +.BU +.Sw -use : +Modify an existing draft. +.BU +.Sw -nouse : +Compose a new draft, possibly taking some existing message as a form. +.P +In either case, the behavior of +.Pn comp +is deterministic. +.P +.Pn send +now operates on the current message in the draft folder by default. +As message and folder can both be overridden by specifying them on +the command line, it is possible to send any message in the mail storage +by simply specifying its number and folder. +In contrast to the other tools, +.Pn send +takes the draft folder as its default folder. +.P +Dropping the draft message concept in favor for the draft folder concept, +removed special cases with regular cases. +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. +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. +Although my part in the draft handling improvement was small, +it was important. + + +.U3 "Trash Folder +.P +Similar to the situation for drafts is the situation for removed messages. +Historically, a message was ``deleted'' by prepending a specific +\fIbackup prefix\fP, usually the comma character, +to the file name. +The specific message would vanish from MH because only files with +non-digit characters in their name are not treated as messages. +Although files remained in the file system, +the messages were no more visible in MH. +To truly delete them, a maintenance job is needed. +Usually a cron job is installed to delete them after a grace time. +For instance: +.VS +find $HOME/Mail -type f -name ',*' -ctime +7 -delete +VE +In such a setup, the original message can be restored +within the grace time interval by stripping the +the backup prefix from the file name. +But one can not rely on this statement. +If the last message of a folder with six messages (1-6) is removed, +message +.Fn 6 , +becomes file +.Fn ,6 . +If then a new message enters the same folder, it will be given +the number one higher than the highest existing message. +In this case the message is named +.Fn 6 +then. +If this message is removed as well, +then the backup of the former message gets overwritten. +Hence, the ability to restore removed messages does not only depend on +the ``sweeping cron job'' but also on the removing of further messages. +It is undesirable to have such obscure and complex mechanisms. +The user should be given a small set of clear assertions. +``Removed files are restorable within a seven-day grace time.'' +is such a clear assertion. +With the addition ``... unless a message with the same name in the +same folder is removed before.'' the statement becomes complex. +A user will hardly be able to keep track of any removal to know +if the assertion still holds true for a specific file. +The the real mechanism is practically obscure to the user. +The consequences of further removals are not obvious. +.P +Further more, the backup files are scattered within the whole mail storage. +This complicates managing them. +It is possible, with help of +.Pn find , +but everything would be more convenient +if the deleted messages would be collected in one place. +.P +The profile entry +.Pe rmmproc +(previously named +.Pe Delete-Prog ) +was introduced very early to improve the situation. +It could be set to any command, which would be executed to removed +the specified messages. +This would override the default action, described above. +Refiling the to-be-removed files to a garbage folder is the usual example. +Nmh's man page +.Mp rmm (1) +proposes to set the +.Pe rmmproc +to +.Cl "refile +d +to move messages to the garbage folder, +.Fn +d , +instead of renaming them with the backup prefix. +The man page proposes additionally the expunge command +.Cl "rm `mhpath +d all` +to empty the garbage folder. +.P +Removing messages in such a way has advantages. +The mail storage is prevented from being cluttered with removed messages +because they are all collected in one place. +Existing and removed messages are thus separated more strictly. +No backup files are silently overwritten. +Most important is the ability to keep removed messages in the MH domain. +Messages in the trash folder can be listed like those in any other folder. +Deleted messages can be displayed like any other messages. +Restoring a deleted messages can be done with +.Pn refile . +All operations on deleted files are still covered by the MH tools. +The trash folder is just like any other folder in the mail storage. +.P +Similar to the draft folder case, I dropped the old backup prefix approach +in favor for replacing it by the better suiting trash folder system. +Hence, +.Pn rmm +calls +.Pn refile +to move the to-be-removed message to the trash folder, +.Fn +trash +by default. +To sweep it clean, one can use +.Cl "rmm -unlink +trash a" , +where the +.Sw -unlink +switch causes the files to be unlinked. +.P +Dropping the legacy approach and completely converting to the new approach +simplified the code base. +The relationship between +.Pn rmm +and +.Pn refile +was inverted. +In mmh, +.Pn rmm +invokes +.Pn refile , +which used to be the other way round. +Yet, the relationship is simpler now. +No more can loops, like described in nmh's man page for +.Mp refile (1), +occur: +.QS +Since +.Pn refile +uses your +.Pe rmmproc +to delete the message, the +.Pe rmmproc +must NOT call +.Pn refile +without specifying +.Sw -normmproc +or you will create an infinite loop. +.QE +.LP +.Pn rmm +either unlinks a message with +.Fu unlink() +or invokes +.Pn refile +to move it to the trash folder. +.Pn refile +does not invoke any tools. +.P + + + +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. + + + + + +.H1 "Styling .P Kernighan and Pike have emphasized the importance of style in the preface of their book: @@ -3357,282 +3690,23 @@ +.H2 "Path Conversion +.P +FIXME! XXX +commit d39e2c447b0d163a5a63f480b23d06edb7a73aa0 +Author: markus schnalke +Date: Fri Dec 9 16:34:57 2011 +0100 -.H1 "Concept Exploitation \"Homogeneity - - -.H2 "Draft Folder -.P -In the beginning, MH had the concept of a draft message. -This is the file -.Fn draft -in the MH directory, which is treated special. -On composing a message, this draft file was used. -As the draft file was one particular file, only one draft could be -managed at any time. -When starting to compose another message before the former one was sent, -the user had to decide among: -.BU -Use the old draft to finish and send it before starting with a new one. -.BU -Discard the old draft, replacing it with the new one. -.BU -Preserve the old draft by refiling it to a folder. -.P -This was, it was only possible to work in alternation on multiple drafts. -Therefore, the current draft needed to be refiled to a folder and -another one re-using for editing. -Working on multiple drafts at the same time was impossible. -The usual approach of switching to a different MH context did not -change anything. -.P -The draft folder facility exists to -allow true parallel editing of drafts, in a straight forward way. -It was introduced by Marshall T. Rose, already in 1984. -Similar to other new features, the draft folder was inactive by default. -Even in nmh, the highly useful draft folder was not available -out-of-the-box. -At least, Richard Coleman added the man page -.Mp mh-draft (5) -to better document the feature. -.P -Not using the draft folder facility has the single advantage of having -the draft file at a static location. -This is simple in simple cases but the concept does not scale for more -complex cases. -The concept of the draft message is too limited for the problem. -Therefore the draft folder was introduced. -It is the more powerful and more natural concept. -The draft folder is a folder like any other folder in MH. -Its messages can be listed like any other messages. -A draft message is no longer a special case. -Tools do not need special switches to work on the draft message. -Hence corner-cases were removed. -.P -The trivial part of the work was activating the draft folder with a -default name. -I chose the name -.Fn +drafts -for obvious reasons. -In consequence, the command line switches -.Sw -draftfolder -and -.Sw -draftmessage -could be removed. -More difficult but also more improving was updating the tools to the -new concept. -For nearly three decades, the tools needed to support two draft handling -approaches. -By fully switching to the draft folder, the tools could be simplified -by dropping the awkward draft message handling code. -.Sw -draft -switches were removed because operating on a draft message is no longer -special. -It became indistinguishable to operating on any other message. -There is no more need to query the user for draft handling. -It is always possible to add another new draft. -Refiling drafts is without difference to refiling other messages. -All these special cases are gone. -Yet, one draft-related switch remained. -.Pn comp -still has -.Sw -[no]use -for switching between two modes: -.BU -.Sw -use : -Modify an existing draft. -.BU -.Sw -nouse : -Compose a new draft, possibly taking some existing message as a form. -.P -In either case, the behavior of -.Pn comp -is deterministic. -.P -.Pn send -now operates on the current message in the draft folder by default. -As message and folder can both be overridden by specifying them on -the command line, it is possible to send any message in the mail storage -by simply specifying its number and folder. -In contrast to the other tools, -.Pn send -takes the draft folder as its default folder. -.P -Dropping the draft message concept in favor for the draft folder concept, -removed special cases with regular cases. -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. -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. -Although my part in the draft handling improvement was small, -it was important. - - - -.H2 "Trash Folder -.P -Similar to the situation for drafts is the situation for removed messages. -Historically, a message was ``deleted'' by prepending a specific -\fIbackup prefix\fP, usually the comma character, -to the file name. -The specific message would vanish from MH because only files with -non-digit characters in their name are not treated as messages. -Although files remained in the file system, -the messages were no more visible in MH. -To truly delete them, a maintenance job is needed. -Usually a cron job is installed to delete them after a grace time. -For instance: -.VS -find $HOME/Mail -type f -name ',*' -ctime +7 -delete -VE -In such a setup, the original message can be restored -within the grace time interval by stripping the -the backup prefix from the file name. -But one can not rely on this statement. -If the last message of a folder with six messages (1-6) is removed, -message -.Fn 6 , -becomes file -.Fn ,6 . -If then a new message enters the same folder, it will be given -the number one higher than the highest existing message. -In this case the message is named -.Fn 6 -then. -If this message is removed as well, -then the backup of the former message gets overwritten. -Hence, the ability to restore removed messages does not only depend on -the ``sweeping cron job'' but also on the removing of further messages. -It is undesirable to have such obscure and complex mechanisms. -The user should be given a small set of clear assertions. -``Removed files are restorable within a seven-day grace time.'' -is such a clear assertion. -With the addition ``... unless a message with the same name in the -same folder is removed before.'' the statement becomes complex. -A user will hardly be able to keep track of any removal to know -if the assertion still holds true for a specific file. -The the real mechanism is practically obscure to the user. -The consequences of further removals are not obvious. -.P -Further more, the backup files are scattered within the whole mail storage. -This complicates managing them. -It is possible, with help of -.Pn find , -but everything would be more convenient -if the deleted messages would be collected in one place. -.P -The profile entry -.Pe rmmproc -(previously named -.Pe Delete-Prog ) -was introduced very early to improve the situation. -It could be set to any command, which would be executed to removed -the specified messages. -This would override the default action, described above. -Refiling the to-be-removed files to a garbage folder is the usual example. -Nmh's man page -.Mp rmm (1) -proposes to set the -.Pe rmmproc -to -.Cl "refile +d -to move messages to the garbage folder, -.Fn +d , -instead of renaming them with the backup prefix. -The man page proposes additionally the expunge command -.Cl "rm `mhpath +d all` -to empty the garbage folder. -.P -Removing messages in such a way has advantages. -The mail storage is prevented from being cluttered with removed messages -because they are all collected in one place. -Existing and removed messages are thus separated more strictly. -No backup files are silently overwritten. -Most important is the ability to keep removed messages in the MH domain. -Messages in the trash folder can be listed like those in any other folder. -Deleted messages can be displayed like any other messages. -Restoring a deleted messages can be done with -.Pn refile . -All operations on deleted files are still covered by the MH tools. -The trash folder is just like any other folder in the mail storage. -.P -Similar to the draft folder case, I dropped the old backup prefix approach -in favor for replacing it by the better suiting trash folder system. -Hence, -.Pn rmm -calls -.Pn refile -to move the to-be-removed message to the trash folder, -.Fn +trash -by default. -To sweep it clean, one can use -.Cl "rmm -unlink +trash a" , -where the -.Sw -unlink -switch causes the files to be unlinked. -.P -Dropping the legacy approach and completely converting to the new approach -simplified the code base. -The relationship between -.Pn rmm -and -.Pn refile -was inverted. -In mmh, -.Pn rmm -invokes -.Pn refile , -which used to be the other way round. -Yet, the relationship is simpler now. -No more can loops, like described in nmh's man page for -.Mp refile (1), -occur: -.QS -Since -.Pn refile -uses your -.Pe rmmproc -to delete the message, the -.Pe rmmproc -must NOT call -.Pn refile -without specifying -.Sw -normmproc -or you will create an infinite loop. -.QE -.LP -.Pn rmm -either unlinks a message with -.Fu unlink() -or invokes -.Pn refile -to move it to the trash folder. -.Pn refile -does not invoke any tools. -.P - - - -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 "Path Notations -.P -FIXME! TODO - - - -.H2 "Of One Cast -.P + 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. diff -r 0b9aa74ced4d -r 7c741bc8f719 intro.roff --- a/intro.roff Mon Jul 02 23:14:19 2012 +0200 +++ b/intro.roff Tue Jul 03 11:11:12 2012 +0200 @@ -165,7 +165,7 @@ .VF input/mh-session -.H1 "nmh: Code and Community +.H1 "nmh .P In order to understand the condition, goals and dynamics of a project, one needs to know the reasons behind them. @@ -377,6 +377,7 @@ appealing MUA should be removed. This includes the mail submission and mail retrieval facilities. Choice should be reduced to the main options. +All tools should be tightly shaped. .IP "Modernizing Mmh's feature set needs to become more modern. Better support for attachment and digital cryptography should be added. @@ -384,9 +385,10 @@ The modern email features need to be readily available, out-of-the-box. On the other hand, bulletin board support and similar obsolete facilities can be dropped out. -Likewise, ancient technologies such as hardcopy terminals -need not to be supported any further. -.IP "Code style +Likewise, ancient technologies should not be supported any further. +The available concepts need to be expanded as far as possible. +A small set of concepts should recur consistently. +.IP "Styling Mmh's source code needs to be updated to modern standards. Standardized library functions should replace non-standard versions whenever possible. @@ -394,8 +396,5 @@ Time and space optimizations should to be replaced by clear and readable code. A uniform programming style should prevail. -.IP "Homogeneity -The available concepts need to be expanded as far as possible. -A small set of concepts should recur consistently. The whole system should appear to be of-one-style; it should feel like being cast as one.