docs/master
diff discussion.roff @ 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 | 4a9a97d9d6b5 |
children | 0b9aa74ced4d |
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