1.1 --- a/ch03.roff	Sat Apr 21 11:40:28 2012 +0200
     1.2 +++ b/ch03.roff	Sun Apr 22 11:49:46 2012 +0200
     1.3 @@ -117,6 +117,64 @@
     1.4  by the removal.
     1.5  
     1.6  
     1.7 +.H1 "Draft and Trash Folders
     1.8 +.U2 "The Draft Folder
     1.9 +.P
    1.10 +Historically, MH provided exactly one draft message, named `\fLdraft\fP' and
    1.11 +being located in the MH directory. When starting to compose another message
    1.12 +before the former one was sent, the user had been questioned wether to use,
    1.13 +refile or replace the old draft. Working on multiple drafts at the same time
    1.14 +was impossible. One could only work on them in alteration by refiling the
    1.15 +previous one to some directory and fetching some other one for reediting. 
    1.16 +This manual draft management needed to be done each time the user wanted
    1.17 +to switch between editing one draft to editing another.
    1.18 +.P
    1.19 +To allow true parallel editing of drafts, in a straight forward way, the
    1.20 +draft folder facility exists. It had been introduced already in July 1984
    1.21 +by Marshall T. Rose. The facility was deactivated by default.
    1.22 +Even in nmh, the draft folder facility remained deactivated by default.
    1.23 +At least, Richard Coleman added the man page \fImh-draft(5)\fI to document
    1.24 +the feature well.
    1.25 +.P
    1.26 +The only advantage of not using the draft folder facility is the static
    1.27 +name of the draft file. This could be an issue for MH frontends like mh-e.
    1.28 +But as they likely want to provide working on multiple drafts in parallel,
    1.29 +the issue is only concerning compatibility. The aim of nmh to stay compatible
    1.30 +prevented the default activation of the draft folder facility.
    1.31 +.P
    1.32 +On the other hand, a draft folder is the much more natural concept than
    1.33 +a draft message. MH's mail storage consists of folders and messages,
    1.34 +the messages named with ascending numbers. A draft message breaks with this
    1.35 +concept by introducing a message in a file named ``draft''. This draft
    1.36 +message is special. It can not be simply listed with the available tools,
    1.37 +but instead special switches were required. I.e. corner-cases were
    1.38 +introduced. A draft folder, in contrast, does not introduce such
    1.39 +corner-cases. The available tools can operate on the messages within that
    1.40 +folder like on any messages within any mail folders. The only difference
    1.41 +is the fact that the default folder for \fLsend\fP is the draft folder,
    1.42 +instead of the current folder, like for all other tools.
    1.43 +.P
    1.44 +The trivial part of the change was activating the draft folder facility
    1.45 +by default and setting a default name for this folder. Obviously, I chose
    1.46 +the name ``\fL+drafts\fP''. This made the \fL\-draftfolder\fP and
    1.47 +\fL\-draftmessage\fP switches useless, thus I could remove them two.
    1.48 +The more difficult but also the part that showed the real improvement,
    1.49 +was updating the tools to the new concept. \fL\-draft\fP switches could
    1.50 +be dropped, as operating on a draft message became indistinguishable to
    1.51 +operating on any other message for the tools. \fLcomp\fP still has its
    1.52 +\fL\-use\fP switch for switching between its two modes: (1) Compose a new
    1.53 +draft, possibly by taking some existing message as a form. (2) Modify
    1.54 +an existing draft. In either case, the behavior of \fLcomp\fP is
    1.55 +deterministic. There is no more need to query the user. I consider this
    1.56 +a major improvement. By making \fLsend\fP simply operate on the current
    1.57 +message in the draft folder by default, with both, message and folder,
    1.58 +overridable by specifying them on the command line, it is now possible
    1.59 +to send any message in the storage by simply specifying its folder and
    1.60 +name.
    1.61 +.P
    1.62 +All theses changes converted special cases to regular cases, thus
    1.63 +simplifying the tools and increasing the flexibility.
    1.64 +
    1.65  
    1.66  .H1 "Paths to ...
    1.67  .P