Mercurial > docs > master

comparison ch03.roff @ 18:db3567c9cc3f

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
style: Added format macros for files, functions, switches, etc. Converted the existing text.
author markus schnalke <meillo@marmaro.de>
date Tue, 24 Apr 2012 16:52:25 +0200
parents b3c37947764e
children ab5253e48c74
comparison
equal deleted inserted replaced
17:b3c37947764e 18:db3567c9cc3f
50 .U2 "MMDF maildrop support 50 .U2 "MMDF maildrop support
51 .P 51 .P
52 I did drop any support for the MMDF maildrop format. This type of format 52 I did drop any support for the MMDF maildrop format. This type of format
53 is conceptionally similar to the mbox format, but uses four bytes with 53 is conceptionally similar to the mbox format, but uses four bytes with
54 value 1 (\fL^A^A^A^A\fP) as message delimiter, 54 value 1 (\fL^A^A^A^A\fP) as message delimiter,
55 instead of the string ``\fLFrom\0\fP''. 55 instead of the string ``\fLFrom\ \fP''.
56 Due to the similarity and mbox being the de-facto standard maildrop 56 Due to the similarity and mbox being the de-facto standard maildrop
57 format on Unix, but also due to the larger influence of Sendmail than MMDF, 57 format on Unix, but also due to the larger influence of Sendmail than MMDF,
58 the MMDF maildrop format had vanished. 58 the MMDF maildrop format had vanished.
59 .P 59 .P
60 The simplifications within the code were only moderate. Switches could 60 The simplifications within the code were only moderate. Switches could
65 The most important changes affect the equally named mail parsing routine in 65 The most important changes affect the equally named mail parsing routine in
66 .L sbr/m_getfld.c . 66 .L sbr/m_getfld.c .
67 The direct MMDF code had been removed, but as now only one packed mailbox 67 The direct MMDF code had been removed, but as now only one packed mailbox
68 format is left, code structure simplifications are likely possible. 68 format is left, code structure simplifications are likely possible.
69 The reason why they are still outstanding is the heavily optimized code 69 The reason why they are still outstanding is the heavily optimized code
70 of \fLm_getfld()\fP. Changes beyond a small local scope \(en 70 of
71 .Fu m_getfld() .
72 Changes beyond a small local scope \(en
71 which restructuring in its core is \(en cause a high risk of damaging 73 which restructuring in its core is \(en cause a high risk of damaging
72 the intricate workings of the optimized code. This problem is know 74 the intricate workings of the optimized code. This problem is know
73 to the developers of nmh, too. They also avoid touching this minefield 75 to the developers of nmh, too. They also avoid touching this minefield
74 if possible. 76 if possible.
75 77
91 hardcopy terminal until Spring 2012, when I finally removed it. 93 hardcopy terminal until Spring 2012, when I finally removed it.
92 I surely would be very happy to see such a terminal in action, maybe 94 I surely would be very happy to see such a terminal in action, maybe
93 actually being able to work on it, but I fear my chances are null. 95 actually being able to work on it, but I fear my chances are null.
94 .P 96 .P
95 The check only prevented a pager to be placed between the outputting 97 The check only prevented a pager to be placed between the outputting
96 program (\fLmhl\fP) and the terminal. This could have been ensured with 98 program (\c
97 the \fL-nomoreproc\fP at the command line statically, too. 99 .Pn mhl )
100 and the terminal. This could have been ensured with
101 the
102 .Sw \-nomoreproc
103 at the command line statically, too.
98 104
99 .U2 "Removed support for header fields 105 .U2 "Removed support for header fields
100 .P 106 .P
101 The `Encrypted' header had been introduced by RFC\^822, but already 107 The `Encrypted' header had been introduced by RFC\^822, but already
102 marked legacy in RFC 2822. It was superseded by FIXME. 108 marked legacy in RFC 2822. It was superseded by FIXME.
118 124
119 125
120 .H1 "Draft and Trash Folders 126 .H1 "Draft and Trash Folders
121 .U2 "Draft Folder 127 .U2 "Draft Folder
122 .P 128 .P
123 Historically, MH provided exactly one draft message, named `\fLdraft\fP' and 129 Historically, MH provided exactly one draft message, named
130 .Fn draft
131 and
124 being located in the MH directory. When starting to compose another message 132 being located in the MH directory. When starting to compose another message
125 before the former one was sent, the user had been questioned wether to use, 133 before the former one was sent, the user had been questioned wether to use,
126 refile or replace the old draft. Working on multiple drafts at the same time 134 refile or replace the old draft. Working on multiple drafts at the same time
127 was impossible. One could only work on them in alteration by refiling the 135 was impossible. One could only work on them in alteration by refiling the
128 previous one to some directory and fetching some other one for reediting. 136 previous one to some directory and fetching some other one for reediting.
131 .P 139 .P
132 To allow true parallel editing of drafts, in a straight forward way, the 140 To allow true parallel editing of drafts, in a straight forward way, the
133 draft folder facility exists. It had been introduced already in July 1984 141 draft folder facility exists. It had been introduced already in July 1984
134 by Marshall T. Rose. The facility was deactivated by default. 142 by Marshall T. Rose. The facility was deactivated by default.
135 Even in nmh, the draft folder facility remained deactivated by default. 143 Even in nmh, the draft folder facility remained deactivated by default.
136 At least, Richard Coleman added the man page \fImh-draft(5)\fP to document 144 At least, Richard Coleman added the man page
145 .Mp mh-draft(5)
146 to document
137 the feature well. 147 the feature well.
138 .P 148 .P
139 The only advantage of not using the draft folder facility is the static 149 The only advantage of not using the draft folder facility is the static
140 name of the draft file. This could be an issue for MH frontends like mh-e. 150 name of the draft file. This could be an issue for MH frontends like mh-e.
141 But as they likely want to provide working on multiple drafts in parallel, 151 But as they likely want to provide working on multiple drafts in parallel,
143 prevented the default activation of the draft folder facility. 153 prevented the default activation of the draft folder facility.
144 .P 154 .P
145 On the other hand, a draft folder is the much more natural concept than 155 On the other hand, a draft folder is the much more natural concept than
146 a draft message. MH's mail storage consists of folders and messages, 156 a draft message. MH's mail storage consists of folders and messages,
147 the messages named with ascending numbers. A draft message breaks with this 157 the messages named with ascending numbers. A draft message breaks with this
148 concept by introducing a message in a file named ``\fLdraft\fP''. This draft 158 concept by introducing a message in a file named
159 .Fn draft .
160 This draft
149 message is special. It can not be simply listed with the available tools, 161 message is special. It can not be simply listed with the available tools,
150 but instead requires special switches. I.e. corner-cases were 162 but instead requires special switches. I.e. corner-cases were
151 introduced. A draft folder, in contrast, does not introduce such 163 introduced. A draft folder, in contrast, does not introduce such
152 corner-cases. The available tools can operate on the messages within that 164 corner-cases. The available tools can operate on the messages within that
153 folder like on any messages within any mail folders. The only difference 165 folder like on any messages within any mail folders. The only difference
154 is the fact that the default folder for \fLsend\fP is the draft folder, 166 is the fact that the default folder for
167 .Pn send
168 is the draft folder,
155 instead of the current folder, like for all other tools. 169 instead of the current folder, like for all other tools.
156 .P 170 .P
157 The trivial part of the change was activating the draft folder facility 171 The trivial part of the change was activating the draft folder facility
158 by default and setting a default name for this folder. Obviously, I chose 172 by default and setting a default name for this folder. Obviously, I chose
159 the name ``\fL+drafts\fP''. This made the \fL\-draftfolder\fP and 173 the name
160 \fL\-draftmessage\fP switches useless, and I could remove them. 174 .Fn +drafts .
175 This made the
176 .Sw \-draftfolder
177 and
178 .Sw \-draftmessage
179 switches useless, and I could remove them.
161 The more difficult but also the part that showed the real improvement, 180 The more difficult but also the part that showed the real improvement,
162 was updating the tools to the new concept. \fL\-draft\fP switches could 181 was updating the tools to the new concept.
182 .Sw \-draft
183 switches could
163 be dropped, as operating on a draft message became indistinguishable to 184 be dropped, as operating on a draft message became indistinguishable to
164 operating on any other message for the tools. \fLcomp\fP still has its 185 operating on any other message for the tools.
165 \fL\-use\fP switch for switching between its two modes: (1) Compose a new 186 .Pn comp
187 still has its
188 .Sw \-use
189 switch for switching between its two modes: (1) Compose a new
166 draft, possibly by taking some existing message as a form. (2) Modify 190 draft, possibly by taking some existing message as a form. (2) Modify
167 an existing draft. In either case, the behavior of \fLcomp\fP is 191 an existing draft. In either case, the behavior of
192 .Pn comp is
168 deterministic. There is no more need to query the user. I consider this 193 deterministic. There is no more need to query the user. I consider this
169 a major improvement. By making \fLsend\fP simply operate on the current 194 a major improvement. By making
195 .Pn send
196 simply operate on the current
170 message in the draft folder by default, with message and folder both 197 message in the draft folder by default, with message and folder both
171 overridable by specifying them on the command line, it is now possible 198 overridable by specifying them on the command line, it is now possible
172 to send a draft anywhere within the storage by simply specifying its folder 199 to send a draft anywhere within the storage by simply specifying its folder
173 and name. 200 and name.
174 .P 201 .P
177 204
178 .U2 "Trash Folder 205 .U2 "Trash Folder
179 .P 206 .P
180 Similar to the situation for drafts is the situation for removed messages. 207 Similar to the situation for drafts is the situation for removed messages.
181 Historically, a message was deleted by renaming. A specific 208 Historically, a message was deleted by renaming. A specific
182 \fIbackup prefix\fP, often comma (\fL,\fP) or hash (\fL#\fP), 209 \fIbackup prefix\fP, often comma (\c
210 .Fn , )
211 or hash (\c
212 .Fn # ),
183 being prepended to the file name. Thus, MH wouldn't recognize the file 213 being prepended to the file name. Thus, MH wouldn't recognize the file
184 as a message anymore, as only files whose name consists of digits only 214 as a message anymore, as only files whose name consists of digits only
185 are treated as messages. The removed messages remained as files in the 215 are treated as messages. The removed messages remained as files in the
186 same directory and needed some maintenance job to truly delete them after 216 same directory and needed some maintenance job to truly delete them after
187 some grace time. Usually, by running a command similar to 217 some grace time. Usually, by running a command similar to
189 find /home/user/Mail \-ctime +7 \-name ',*' | xargs rm 219 find /home/user/Mail \-ctime +7 \-name ',*' | xargs rm
190 .DE 220 .DE
191 in a cron job. Within the grace time interval 221 in a cron job. Within the grace time interval
192 the original message could be restored by stripping the 222 the original message could be restored by stripping the
193 the backup prefix from the file name. If however, the last message of 223 the backup prefix from the file name. If however, the last message of
194 a folder is been removed \(en say message `\fL6\fP' becomes file 224 a folder is been removed \(en say message
195 `\fL,6\fP' \(en and a new message enters the same folder, thus the same 225 .Fn 6
196 numbered being given again \(en in our case `\fL6\fP' \(en, if that one 226 becomes file
227 .Fn ,6
228 \(en and a new message enters the same folder, thus the same
229 numbered being given again \(en in our case
230 .Fn 6
231 \(en, if that one
197 is removed too, then the backup of the former message gets overwritten. 232 is removed too, then the backup of the former message gets overwritten.
198 Thus, the ability to restore removed messages does not only depend on 233 Thus, the ability to restore removed messages does not only depend on
199 the ``sweeping cron job'' but also on the removing of further messages. 234 the ``sweeping cron job'' but also on the removing of further messages.
200 This is undesireable, because the real mechanism is hidden from the user 235 This is undesireable, because the real mechanism is hidden from the user
201 and the concequences of further removals are not always obvious. 236 and the concequences of further removals are not always obvious.
202 Further more, the backup files are scattered within the whole mail 237 Further more, the backup files are scattered within the whole mail
203 storage, instead of being collected at one place. 238 storage, instead of being collected at one place.
204 .P 239 .P
205 To improve the situation, the profile entry \fIrmmproc\fP 240 To improve the situation, the profile entry
206 (previously named \fIDelete-Prog\fP) was introduced, very early. 241 .Pe rmmproc
242 (previously named
243 .Pe Delete-Prog )
244 was introduced, very early.
207 It could be set to any command, which would care for the mail removal 245 It could be set to any command, which would care for the mail removal
208 instead of taking the default action, described above. 246 instead of taking the default action, described above.
209 Refiling the to-be-removed files to some wastebin folder was a common 247 Refiling the to-be-removed files to some wastebin folder was a common
210 example. Nmh's man page for \fLrmm(1)\fP proposes `\fLrefile +d\fP' 248 example. Nmh's man page
211 to move messages to the wastebin and `\fLrm `mhpath +d all`\fP' 249 .Mp rmm(1)
250 proposes
251 .Cl "refile +d
252 to move messages to the wastebin and
253 .Cl "rm `mhpath +d all`
212 the empty the wastebin. 254 the empty the wastebin.
213 Managing the message removal this way is a sane approach. It keeps 255 Managing the message removal this way is a sane approach. It keeps
214 the removed messages in one place, makes it easy to remove the backup 256 the removed messages in one place, makes it easy to remove the backup
215 files, and, most important, enables the user to use the tools of MH 257 files, and, most important, enables the user to use the tools of MH
216 itself to operate on the removed messages. One can \fLscan\fP them, 258 itself to operate on the removed messages. One can
217 \fLshow\fP them, and restore them with \fLrefile(1)\fP. There's no more 259 .Pn scan
218 need to use \fLmhpath\fP to switch over from MH tools to Unix tools 260 them,
219 \(en MH can do it all itself. 261 .Pn show
220 .P 262 them, and restore them with
221 This apporach is matches perfect with the concepts of MH, thus making 263 .Pn refile .
264 There's no more
265 need to use
266 .Pn mhpath
267 to switch over from MH tools to Unix tools \(en MH can do it all itself.
268 .P
269 This apporach matches perfect with the concepts of MH, thus making
222 it powerful. Hence, I made it the default. And even more, I also 270 it powerful. Hence, I made it the default. And even more, I also
223 removed the old backup prefix approach, as it is clearly less powerful. 271 removed the old backup prefix approach, as it is clearly less powerful.
224 Keeping unused alternative in the code is a bad choice as they likely 272 Keeping unused alternative in the code is a bad choice as they likely
225 gather bugs, by not being constantly tested. Also, the increased code 273 gather bugs, by not being constantly tested. Also, the increased code
226 size and more conditions crease the maintenance costs. By strictly 274 size and more conditions crease the maintenance costs. By strictly
227 converting to the trash folder approach, I simplified the code base. 275 converting to the trash folder approach, I simplified the code base.
228 \fLrmm(1)\fP calls \fLrefile(1)\fP internally to move the to-be-removed 276 .Pn rmm
229 message to the trash folder (`\fL+trash\fP' by default). Messages 277 calls
278 .Pn refile
279 internally to move the to-be-removed
280 message to the trash folder (\c
281 .Fn +trash
282 by default). Messages
230 there can be operated on like on any other message in the storage. 283 there can be operated on like on any other message in the storage.
231 The sweep clean, one can use `\fLrmm \-unlink +trash a\fP', where 284 The sweep clean, one can use
232 the `\fL\-unlink\fP' switch causes the files to be truly unliked instead 285 .Cl "rmm \-unlink +trash a" ,
286 where the
287 .Sw \-unlink
288 switch causes the files to be truly unliked instead
233 of moved to the trash folder. 289 of moved to the trash folder.
234 290
235 291
236 .H1 "MH Directory Split 292 .H1 "MH Directory Split
237 .P 293 .P
238 294 Historically, a personal MH setup had consisted of two things:
295 the
239 296
240 297
241 .H1 "Path Notations 298 .H1 "Path Notations
242 .P 299 .P
243 foo 300 foo