--- 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 <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
 .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 <meillo@marmaro.de>
+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 <meillo@marmaro.de>
+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 @@
 
 
 
-
-
-
-.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.
+.H2 "Path Conversion
 .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.
-
+FIXME! XXX
 
 
-.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
+commit d39e2c447b0d163a5a63f480b23d06edb7a73aa0
+Author: markus schnalke <meillo@marmaro.de>
+Date:   Fri Dec 9 16:34:57 2011 +0100
 
-
-
-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.

--- 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.