docs/master

changeset 129:01af3c0dfe7b

Reworked the text about the Draft Folder.
author markus schnalke <meillo@marmaro.de>
date Mon, 02 Jul 2012 17:59:21 +0200
parents 76c440261ebb
children 0b9aa74ced4d
files discussion.roff
diffstat 1 files changed, 95 insertions(+), 83 deletions(-) [+]
line diff
     1.1 --- a/discussion.roff	Mon Jul 02 13:30:22 2012 +0200
     1.2 +++ b/discussion.roff	Mon Jul 02 17:59:21 2012 +0200
     1.3 @@ -3360,106 +3360,118 @@
     1.4  
     1.5  
     1.6  
     1.7 -.H1 "Concept Exploitation/Homogeneity
     1.8 +.H1 "Concept Exploitation \"Homogeneity
     1.9  
    1.10  
    1.11  .H2 "Draft Folder
    1.12  .P
    1.13 -Historically, MH provided exactly one draft message, named
    1.14 +In the beginning, MH had the concept of a draft message.
    1.15 +This is the file
    1.16  .Fn draft
    1.17 -and
    1.18 -being located in the MH directory.
    1.19 -When starting to compose another message
    1.20 -before the former one was sent, the user had been questioned whether to use,
    1.21 -refile or replace the old draft.
    1.22 -Working on multiple drafts at the same time
    1.23 -was impossible.
    1.24 -One could only work on them in alteration by refiling the
    1.25 -previous one to some directory and fetching some other one for reediting.
    1.26 -This manual draft management needed to be done each time the user wanted
    1.27 -to switch between editing one draft to editing another.
    1.28 +in the MH directory, which is treated special.
    1.29 +On composing a message, this draft file was used.
    1.30 +As the draft file was one particular file, only one draft could be
    1.31 +managed at any time.
    1.32 +When starting to compose another message before the former one was sent,
    1.33 +the user had to decide among:
    1.34 +.BU
    1.35 +Use the old draft to finish and send it before starting with a new one.
    1.36 +.BU
    1.37 +Discard the old draft, replacing it with the new one.
    1.38 +.BU
    1.39 +Preserve the old draft by refiling it to a folder.
    1.40  .P
    1.41 -To allow true parallel editing of drafts, in a straight forward way, the
    1.42 -draft folder facility exists.
    1.43 -It had been introduced already in July 1984
    1.44 -by Marshall T. Rose.
    1.45 -The facility was inactive by default.
    1.46 -Even in nmh, the draft folder facility remained inactive by default.
    1.47 +This was, it was only possible to work in alternation on multiple drafts.
    1.48 +Therefore, the current draft needed to be refiled to a folder and
    1.49 +another one re-using for editing.
    1.50 +Working on multiple drafts at the same time was impossible.
    1.51 +The usual approach of switching to a different MH context did not
    1.52 +change anything.
    1.53 +.P
    1.54 +The draft folder facility exists to
    1.55 +allow true parallel editing of drafts, in a straight forward way.
    1.56 +It was introduced by Marshall T. Rose, already in 1984.
    1.57 +Similar to other new features, the draft folder was inactive by default.
    1.58 +Even in nmh, the highly useful draft folder was not available
    1.59 +out-of-the-box.
    1.60  At least, Richard Coleman added the man page
    1.61 -.Mp mh-draft(5)
    1.62 -to document
    1.63 -the feature well.
    1.64 +.Mp mh-draft (5)
    1.65 +to better document the feature.
    1.66  .P
    1.67 -The only advantage of not using the draft folder facility is the static
    1.68 -name of the draft file.
    1.69 -This could be an issue for MH front-ends like mh-e.
    1.70 -But as they likely want to provide working on multiple drafts in parallel,
    1.71 -the issue is only concerning compatibility.
    1.72 -The aim of nmh to stay compatible
    1.73 -prevented the default activation of the draft folder facility.
    1.74 +Not using the draft folder facility has the single advantage of having
    1.75 +the draft file at a static location.
    1.76 +This is simple in simple cases but the concept does not scale for more
    1.77 +complex cases.
    1.78 +The concept of the draft message is too limited for the problem.
    1.79 +Therefore the draft folder was introduced.
    1.80 +It is the more powerful and more natural concept.
    1.81 +The draft folder is a folder like any other folder in MH.
    1.82 +Its messages can be listed like any other messages.
    1.83 +A draft message is no longer a special case.
    1.84 +Tools do not need special switches to work on the draft message.
    1.85 +Hence corner-cases were removed.
    1.86  .P
    1.87 -On the other hand, a draft folder is the much more natural concept than
    1.88 -a draft message.
    1.89 -MH's mail storage consists of folders and messages,
    1.90 -the messages named with ascending numbers.
    1.91 -A draft message breaks with this
    1.92 -concept by introducing a message in a file named
    1.93 -.Fn draft .
    1.94 -This draft
    1.95 -message is special.
    1.96 -It can not be simply listed with the available tools,
    1.97 -but instead requires special switches.
    1.98 -I.e. corner-cases were
    1.99 -introduced.
   1.100 -A draft folder, in contrast, does not introduce such
   1.101 -corner-cases.
   1.102 -The available tools can operate on the messages within that
   1.103 -folder like on any messages within any mail folders.
   1.104 -The only difference
   1.105 -is the fact that the default folder for
   1.106 -.Pn send
   1.107 -is the draft folder,
   1.108 -instead of the current folder, like for all other tools.
   1.109 -.P
   1.110 -The trivial part of the change was activating the draft folder facility
   1.111 -by default and setting a default name for this folder.
   1.112 -Obviously, I chose
   1.113 -the name
   1.114 -.Fn +drafts .
   1.115 -This made the
   1.116 +The trivial part of the work was activating the draft folder with a
   1.117 +default name.
   1.118 +I chose the name
   1.119 +.Fn +drafts
   1.120 +for obvious reasons.
   1.121 +In consequence, the command line switches
   1.122  .Sw -draftfolder
   1.123  and
   1.124  .Sw -draftmessage
   1.125 -switches useless, and I could remove them.
   1.126 -The more difficult but also the part that showed the real improvement,
   1.127 -was updating the tools to the new concept.
   1.128 +could be removed.
   1.129 +More difficult but also more improving was updating the tools to the
   1.130 +new concept.
   1.131 +For nearly three decades, the tools needed to support two draft handling
   1.132 +approaches.
   1.133 +By fully switching to the draft folder, the tools could be simplified
   1.134 +by dropping the awkward draft message handling code.
   1.135  .Sw -draft
   1.136 -switches could
   1.137 -be dropped, as operating on a draft message became indistinguishable to
   1.138 -operating on any other message for the tools.
   1.139 +switches were removed because operating on a draft message is no longer
   1.140 +special.
   1.141 +It became indistinguishable to operating on any other message.
   1.142 +There is no more need to query the user for draft handling.
   1.143 +It is always possible to add another new draft.
   1.144 +Refiling drafts is without difference to refiling other messages.
   1.145 +All these special cases are gone.
   1.146 +Yet, one draft-related switch remained.
   1.147  .Pn comp
   1.148 -still has its
   1.149 -.Sw -use
   1.150 -switch for switching between its two modes: (1) Compose a new
   1.151 -draft, possibly by taking some existing message as a form.
   1.152 -(2) Modify
   1.153 -an existing draft.
   1.154 +still has
   1.155 +.Sw -[no]use
   1.156 +for switching between two modes:
   1.157 +.BU
   1.158 +.Sw -use :
   1.159 +Modify an existing draft.
   1.160 +.BU
   1.161 +.Sw -nouse :
   1.162 +Compose a new draft, possibly taking some existing message as a form.
   1.163 +.P
   1.164  In either case, the behavior of
   1.165 -.Pn comp is
   1.166 -deterministic.
   1.167 -There is no more need to query the user.
   1.168 -I consider this
   1.169 -a major improvement.
   1.170 -By making
   1.171 +.Pn comp
   1.172 +is deterministic.
   1.173 +.P
   1.174  .Pn send
   1.175 -simply operate on the current
   1.176 -message in the draft folder by default, with message and folder both
   1.177 -overridable by specifying them on the command line, it is now possible
   1.178 -to send a draft anywhere within the storage by simply specifying its folder
   1.179 -and name.
   1.180 +now operates on the current message in the draft folder by default.
   1.181 +As message and folder can both be overridden by specifying them on
   1.182 +the command line, it is possible to send any message in the mail storage
   1.183 +by simply specifying its number and folder.
   1.184 +In contrast to the other tools,
   1.185 +.Pn send
   1.186 +takes the draft folder as its default folder.
   1.187  .P
   1.188 -All theses changes converted special cases to regular cases, thus
   1.189 -simplifying the tools and increasing the flexibility.
   1.190 +Dropping the draft message concept in favor for the draft folder concept,
   1.191 +removed special cases with regular cases.
   1.192 +This simplified the source code of the tools, as well as the concepts.
   1.193 +In mmh, draft management does not break with the MH concepts
   1.194 +but applies them.
   1.195 +Most of the work was already done by Rose in the eighties.
   1.196 +The original improvement in mmh is dropping the draft message approach
   1.197 +completely and thus simplifying the tools, the documentation and the
   1.198 +system as a whole.
   1.199 +Although my part in the draft handling improvement was small,
   1.200 +it was important.
   1.201 +
   1.202  
   1.203  
   1.204  .H2 "Trash Folder