--- a/discussion.roff	Mon Jul 02 13:30:22 2012 +0200
+++ b/discussion.roff	Mon Jul 02 17:59:21 2012 +0200
@@ -3360,106 +3360,118 @@
 
 
 
-.H1 "Concept Exploitation/Homogeneity
+.H1 "Concept Exploitation \"Homogeneity
 
 
 .H2 "Draft Folder
 .P
-Historically, MH provided exactly one draft message, named
+In the beginning, MH had the concept of a draft message.
+This is the file
 .Fn draft
-and
-being located in the MH directory.
-When starting to compose another message
-before the former one was sent, the user had been questioned whether to use,
-refile or replace the old draft.
-Working on multiple drafts at the same time
-was impossible.
-One could only work on them in alteration by refiling the
-previous one to some directory and fetching some other one for reediting.
-This manual draft management needed to be done each time the user wanted
-to switch between editing one draft to editing another.
+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
-To allow true parallel editing of drafts, in a straight forward way, the
-draft folder facility exists.
-It had been introduced already in July 1984
-by Marshall T. Rose.
-The facility was inactive by default.
-Even in nmh, the draft folder facility remained inactive by default.
-At least, Richard Coleman added the man page
-.Mp mh-draft(5)
-to document
-the feature well.
+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 only advantage of not using the draft folder facility is the static
-name of the draft file.
-This could be an issue for MH front-ends like mh-e.
-But as they likely want to provide working on multiple drafts in parallel,
-the issue is only concerning compatibility.
-The aim of nmh to stay compatible
-prevented the default activation of the draft folder facility.
+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
-On the other hand, a draft folder is the much more natural concept than
-a draft message.
-MH's mail storage consists of folders and messages,
-the messages named with ascending numbers.
-A draft message breaks with this
-concept by introducing a message in a file named
-.Fn draft .
-This draft
-message is special.
-It can not be simply listed with the available tools,
-but instead requires special switches.
-I.e. corner-cases were
-introduced.
-A draft folder, in contrast, does not introduce such
-corner-cases.
-The available tools can operate on the messages within that
-folder like on any messages within any mail folders.
-The only difference
-is the fact that the default folder for
-.Pn send
-is the draft folder,
-instead of the current folder, like for all other tools.
+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 change was activating the draft folder facility
-by default and setting a default name for this folder.
-Obviously, I chose
-the name
-.Fn +drafts .
-This made the
+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
-switches useless, and I could remove them.
-The more difficult but also the part that showed the real improvement,
-was updating the tools to the new concept.
+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 could
-be dropped, as operating on a draft message became indistinguishable to
-operating on any other message for the tools.
+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 its
-.Sw -use
-switch for switching between its two modes: (1) Compose a new
-draft, possibly by taking some existing message as a form.
-(2) Modify
-an existing draft.
+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.
-There is no more need to query the user.
-I consider this
-a major improvement.
-By making
+.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
-simply operate on the current
-message in the draft folder by default, with message and folder both
-overridable by specifying them on the command line, it is now possible
-to send a draft anywhere within the storage by simply specifying its folder
-and name.
+takes the draft folder as its default folder.
 .P
-All theses changes converted special cases to regular cases, thus
-simplifying the tools and increasing the flexibility.
+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