1.1 --- a/discussion.roff	Mon Jul 02 23:14:19 2012 +0200
     1.2 +++ b/discussion.roff	Tue Jul 03 11:11:12 2012 +0200
     1.3 @@ -424,7 +424,46 @@
     1.4  is unrelated to the rest of the project.
     1.5  
     1.6  
     1.7 -.H2 "\fLshow\fP and \fPmhshow\fP
     1.8 +.H3 "Profile Reading
     1.9 +.P
    1.10 +FIXME XXX
    1.11 +
    1.12 +commit 3e017a7abbdf69bf0dff7a4073275961eda1ded8
    1.13 +Author: markus schnalke <meillo@marmaro.de>
    1.14 +Date:   Wed Jun 27 14:23:35 2012 +0200
    1.15 +
    1.16 +    spost: Read profile and context now. Removed -library switch.
    1.17 +    spost is a full part of the mmh toolchest, hence, it shall read the
    1.18 +    profile/context. This will remove the need to pass profile information
    1.19 +    from send to spost via command line switches.
    1.20 +    In January 2012, there had been a discussion on the nmh-workers ML
    1.21 +    whether post should read the profile/context. There wasn't a clear
    1.22 +    answer. It behavior was mainly motivated by the historic situation,
    1.23 +    it seems. My opinion on the topic goes into the direction that every
    1.24 +    tool that is part of the mmh toolchest should read the profile. That
    1.25 +    is a clear and simple concept. Using MH tools without wanting to
    1.26 +    interact with MH (like mhmail had been) is no more a practical problem.
    1.27 +
    1.28 +commit 32d4f9daaa70519be3072479232ff7be0500d009
    1.29 +Author: markus schnalke <meillo@marmaro.de>
    1.30 +Date:   Wed Jun 27 13:15:47 2012 +0200
    1.31 +
    1.32 +    mhmail: Read the context!
    1.33 +    mhmail will change from a mailx-replacment to an alternative to
    1.34 +    `comp -ed prompter', thus being a send front-end. Hence, mhmail
    1.35 +    should not stay outside the profile/context respecting mmh toolchest.
    1.36 +
    1.37 +
    1.38 +slocal
    1.39 +
    1.40 +
    1.41 +
    1.42 +
    1.43 +.H2 "Displaying Messages
    1.44 +.P
    1.45 +FIXME XXX
    1.46 +
    1.47 +.U3 "\fLshow\fP and \fPmhshow\fP
    1.48  .P
    1.49  Since the very beginning \(en already in the first concept paper \(en
    1.50  .Pn show
    1.51 @@ -563,6 +602,32 @@
    1.52  supporting MIME demands for higher essential complexity.
    1.53  
    1.54  
    1.55 +.U3 "Scan Listings
    1.56 +.P
    1.57 +FIXME XXX
    1.58 +
    1.59 +.P
    1.60 +
    1.61 +commit c20e315f9fb9f0f0955749726dbf4fd897cd9f48
    1.62 +Author: markus schnalke <meillo@marmaro.de>
    1.63 +Date:   Fri Dec 9 21:56:44 2011 +0100
    1.64 +
    1.65 +    Adjusted the default scan listing: remove the body preview
    1.66 +    The original listing is still available as etc/scan.nmh
    1.67 +
    1.68 +commit 70b2643e0da8485174480c644ad9785c84f5bff4
    1.69 +Author: markus schnalke <meillo@marmaro.de>
    1.70 +Date:   Mon Jan 30 16:16:26 2012 +0100
    1.71 +
    1.72 +    Scan listings shall not contain body content. Hence, removed this feature.
    1.73 +    Scan listings shall operator on message headers and non-message information
    1.74 +    only. Displaying the beginning of the body complicates everything too much.
    1.75 +    That's no surprise, because it's something completely different. If you
    1.76 +    want to examine the body, then use show(1)/mhshow(1).
    1.77 +    Changed the default scan formats accordingly.
    1.78 +
    1.79 +
    1.80 +
    1.81  .H2 "Configure Options
    1.82  .P
    1.83  Customization is a double-edged sword.
    1.84 @@ -2474,8 +2539,276 @@
    1.85  
    1.86  
    1.87  
    1.88 +.H2 "Drafts and Trash Folder
    1.89 +.P
    1.90  
    1.91 -.H1 "Style
    1.92 +.U3 "Draft Folder
    1.93 +.P
    1.94 +In the beginning, MH had the concept of a draft message.
    1.95 +This is the file
    1.96 +.Fn draft
    1.97 +in the MH directory, which is treated special.
    1.98 +On composing a message, this draft file was used.
    1.99 +As the draft file was one particular file, only one draft could be
   1.100 +managed at any time.
   1.101 +When starting to compose another message before the former one was sent,
   1.102 +the user had to decide among:
   1.103 +.BU
   1.104 +Use the old draft to finish and send it before starting with a new one.
   1.105 +.BU
   1.106 +Discard the old draft, replacing it with the new one.
   1.107 +.BU
   1.108 +Preserve the old draft by refiling it to a folder.
   1.109 +.P
   1.110 +This was, it was only possible to work in alternation on multiple drafts.
   1.111 +Therefore, the current draft needed to be refiled to a folder and
   1.112 +another one re-using for editing.
   1.113 +Working on multiple drafts at the same time was impossible.
   1.114 +The usual approach of switching to a different MH context did not
   1.115 +change anything.
   1.116 +.P
   1.117 +The draft folder facility exists to
   1.118 +allow true parallel editing of drafts, in a straight forward way.
   1.119 +It was introduced by Marshall T. Rose, already in 1984.
   1.120 +Similar to other new features, the draft folder was inactive by default.
   1.121 +Even in nmh, the highly useful draft folder was not available
   1.122 +out-of-the-box.
   1.123 +At least, Richard Coleman added the man page
   1.124 +.Mp mh-draft (5)
   1.125 +to better document the feature.
   1.126 +.P
   1.127 +Not using the draft folder facility has the single advantage of having
   1.128 +the draft file at a static location.
   1.129 +This is simple in simple cases but the concept does not scale for more
   1.130 +complex cases.
   1.131 +The concept of the draft message is too limited for the problem.
   1.132 +Therefore the draft folder was introduced.
   1.133 +It is the more powerful and more natural concept.
   1.134 +The draft folder is a folder like any other folder in MH.
   1.135 +Its messages can be listed like any other messages.
   1.136 +A draft message is no longer a special case.
   1.137 +Tools do not need special switches to work on the draft message.
   1.138 +Hence corner-cases were removed.
   1.139 +.P
   1.140 +The trivial part of the work was activating the draft folder with a
   1.141 +default name.
   1.142 +I chose the name
   1.143 +.Fn +drafts
   1.144 +for obvious reasons.
   1.145 +In consequence, the command line switches
   1.146 +.Sw -draftfolder
   1.147 +and
   1.148 +.Sw -draftmessage
   1.149 +could be removed.
   1.150 +More difficult but also more improving was updating the tools to the
   1.151 +new concept.
   1.152 +For nearly three decades, the tools needed to support two draft handling
   1.153 +approaches.
   1.154 +By fully switching to the draft folder, the tools could be simplified
   1.155 +by dropping the awkward draft message handling code.
   1.156 +.Sw -draft
   1.157 +switches were removed because operating on a draft message is no longer
   1.158 +special.
   1.159 +It became indistinguishable to operating on any other message.
   1.160 +There is no more need to query the user for draft handling.
   1.161 +It is always possible to add another new draft.
   1.162 +Refiling drafts is without difference to refiling other messages.
   1.163 +All these special cases are gone.
   1.164 +Yet, one draft-related switch remained.
   1.165 +.Pn comp
   1.166 +still has
   1.167 +.Sw -[no]use
   1.168 +for switching between two modes:
   1.169 +.BU
   1.170 +.Sw -use :
   1.171 +Modify an existing draft.
   1.172 +.BU
   1.173 +.Sw -nouse :
   1.174 +Compose a new draft, possibly taking some existing message as a form.
   1.175 +.P
   1.176 +In either case, the behavior of
   1.177 +.Pn comp
   1.178 +is deterministic.
   1.179 +.P
   1.180 +.Pn send
   1.181 +now operates on the current message in the draft folder by default.
   1.182 +As message and folder can both be overridden by specifying them on
   1.183 +the command line, it is possible to send any message in the mail storage
   1.184 +by simply specifying its number and folder.
   1.185 +In contrast to the other tools,
   1.186 +.Pn send
   1.187 +takes the draft folder as its default folder.
   1.188 +.P
   1.189 +Dropping the draft message concept in favor for the draft folder concept,
   1.190 +removed special cases with regular cases.
   1.191 +This simplified the source code of the tools, as well as the concepts.
   1.192 +In mmh, draft management does not break with the MH concepts
   1.193 +but applies them.
   1.194 +Most of the work was already done by Rose in the eighties.
   1.195 +The original improvement in mmh is dropping the draft message approach
   1.196 +completely and thus simplifying the tools, the documentation and the
   1.197 +system as a whole.
   1.198 +Although my part in the draft handling improvement was small,
   1.199 +it was important.
   1.200 +
   1.201 +
   1.202 +.U3 "Trash Folder
   1.203 +.P
   1.204 +Similar to the situation for drafts is the situation for removed messages.
   1.205 +Historically, a message was ``deleted'' by prepending a specific
   1.206 +\fIbackup prefix\fP, usually the comma character,
   1.207 +to the file name.
   1.208 +The specific message would vanish from MH because only files with
   1.209 +non-digit characters in their name are not treated as messages.
   1.210 +Although files remained in the file system,
   1.211 +the messages were no more visible in MH.
   1.212 +To truly delete them, a maintenance job is needed.
   1.213 +Usually a cron job is installed to delete them after a grace time.
   1.214 +For instance:
   1.215 +.VS
   1.216 +find $HOME/Mail -type f -name ',*' -ctime +7 -delete
   1.217 +VE
   1.218 +In such a setup, the original message can be restored
   1.219 +within the grace time interval by stripping the
   1.220 +the backup prefix from the file name.
   1.221 +But one can not rely on this statement.
   1.222 +If the last message of a folder with six messages (1-6) is removed,
   1.223 +message
   1.224 +.Fn 6 ,
   1.225 +becomes file
   1.226 +.Fn ,6 .
   1.227 +If then a new message enters the same folder, it will be given
   1.228 +the number one higher than the highest existing message.
   1.229 +In this case the message is named
   1.230 +.Fn 6
   1.231 +then.
   1.232 +If this message is removed as well,
   1.233 +then the backup of the former message gets overwritten.
   1.234 +Hence, the ability to restore removed messages does not only depend on
   1.235 +the ``sweeping cron job'' but also on the removing of further messages.
   1.236 +It is undesirable to have such obscure and complex mechanisms.
   1.237 +The user should be given a small set of clear assertions.
   1.238 +``Removed files are restorable within a seven-day grace time.''
   1.239 +is such a clear assertion.
   1.240 +With the addition ``... unless a message with the same name in the
   1.241 +same folder is removed before.'' the statement becomes complex.
   1.242 +A user will hardly be able to keep track of any removal to know
   1.243 +if the assertion still holds true for a specific file.
   1.244 +The the real mechanism is practically obscure to the user.
   1.245 +The consequences of further removals are not obvious.
   1.246 +.P
   1.247 +Further more, the backup files are scattered within the whole mail storage.
   1.248 +This complicates managing them.
   1.249 +It is possible, with help of
   1.250 +.Pn find ,
   1.251 +but everything would be more convenient
   1.252 +if the deleted messages would be collected in one place.
   1.253 +.P
   1.254 +The profile entry
   1.255 +.Pe rmmproc
   1.256 +(previously named
   1.257 +.Pe Delete-Prog )
   1.258 +was introduced very early to improve the situation.
   1.259 +It could be set to any command, which would be executed to removed
   1.260 +the specified messages.
   1.261 +This would override the default action, described above.
   1.262 +Refiling the to-be-removed files to a garbage folder is the usual example.
   1.263 +Nmh's man page
   1.264 +.Mp rmm (1)
   1.265 +proposes to set the
   1.266 +.Pe rmmproc
   1.267 +to
   1.268 +.Cl "refile +d
   1.269 +to move messages to the garbage folder,
   1.270 +.Fn +d ,
   1.271 +instead of renaming them with the backup prefix.
   1.272 +The man page proposes additionally the expunge command
   1.273 +.Cl "rm `mhpath +d all`
   1.274 +to empty the garbage folder.
   1.275 +.P
   1.276 +Removing messages in such a way has advantages.
   1.277 +The mail storage is prevented from being cluttered with removed messages
   1.278 +because they are all collected in one place.
   1.279 +Existing and removed messages are thus separated more strictly.
   1.280 +No backup files are silently overwritten.
   1.281 +Most important is the ability to keep removed messages in the MH domain.
   1.282 +Messages in the trash folder can be listed like those in any other folder.
   1.283 +Deleted messages can be displayed like any other messages.
   1.284 +Restoring a deleted messages can be done with
   1.285 +.Pn refile .
   1.286 +All operations on deleted files are still covered by the MH tools.
   1.287 +The trash folder is just like any other folder in the mail storage.
   1.288 +.P
   1.289 +Similar to the draft folder case, I dropped the old backup prefix approach
   1.290 +in favor for replacing it by the better suiting trash folder system.
   1.291 +Hence,
   1.292 +.Pn rmm
   1.293 +calls
   1.294 +.Pn refile
   1.295 +to move the to-be-removed message to the trash folder,
   1.296 +.Fn +trash
   1.297 +by default.
   1.298 +To sweep it clean, one can use
   1.299 +.Cl "rmm -unlink +trash a" ,
   1.300 +where the
   1.301 +.Sw -unlink
   1.302 +switch causes the files to be unlinked.
   1.303 +.P
   1.304 +Dropping the legacy approach and completely converting to the new approach
   1.305 +simplified the code base.
   1.306 +The relationship between
   1.307 +.Pn rmm
   1.308 +and
   1.309 +.Pn refile
   1.310 +was inverted.
   1.311 +In mmh,
   1.312 +.Pn rmm
   1.313 +invokes
   1.314 +.Pn refile ,
   1.315 +which used to be the other way round.
   1.316 +Yet, the relationship is simpler now.
   1.317 +No more can loops, like described in nmh's man page for
   1.318 +.Mp refile (1),
   1.319 +occur:
   1.320 +.QS
   1.321 +Since
   1.322 +.Pn refile
   1.323 +uses your
   1.324 +.Pe rmmproc
   1.325 +to delete the message, the
   1.326 +.Pe rmmproc
   1.327 +must NOT call
   1.328 +.Pn refile
   1.329 +without specifying
   1.330 +.Sw -normmproc
   1.331 +or you will create an infinite loop.
   1.332 +.QE
   1.333 +.LP
   1.334 +.Pn rmm
   1.335 +either unlinks a message with
   1.336 +.Fu unlink()
   1.337 +or invokes
   1.338 +.Pn refile
   1.339 +to move it to the trash folder.
   1.340 +.Pn refile
   1.341 +does not invoke any tools.
   1.342 +.P
   1.343 +
   1.344 +
   1.345 +
   1.346 +Keeping unused alternative in the code is a bad choice as they likely
   1.347 +gather bugs, by not being constantly tested.
   1.348 +Also, the increased code
   1.349 +size and more conditions crease the maintenance costs.
   1.350 +
   1.351 +By generalizing the message removal in a way that it becomes covered
   1.352 +by the MH concepts makes the whole system more powerful.
   1.353 +
   1.354 +
   1.355 +
   1.356 +
   1.357 +
   1.358 +.H1 "Styling
   1.359  .P
   1.360  Kernighan and Pike have emphasized the importance of style in the
   1.361  preface of their book:
   1.362 @@ -3357,282 +3690,23 @@
   1.363  
   1.364  
   1.365  
   1.366 +.H2 "Path Conversion
   1.367 +.P
   1.368 +FIXME! XXX
   1.369  
   1.370  
   1.371 +commit d39e2c447b0d163a5a63f480b23d06edb7a73aa0
   1.372 +Author: markus schnalke <meillo@marmaro.de>
   1.373 +Date:   Fri Dec 9 16:34:57 2011 +0100
   1.374  
   1.375 -.H1 "Concept Exploitation \"Homogeneity
   1.376 -
   1.377 -
   1.378 -.H2 "Draft Folder
   1.379 -.P
   1.380 -In the beginning, MH had the concept of a draft message.
   1.381 -This is the file
   1.382 -.Fn draft
   1.383 -in the MH directory, which is treated special.
   1.384 -On composing a message, this draft file was used.
   1.385 -As the draft file was one particular file, only one draft could be
   1.386 -managed at any time.
   1.387 -When starting to compose another message before the former one was sent,
   1.388 -the user had to decide among:
   1.389 -.BU
   1.390 -Use the old draft to finish and send it before starting with a new one.
   1.391 -.BU
   1.392 -Discard the old draft, replacing it with the new one.
   1.393 -.BU
   1.394 -Preserve the old draft by refiling it to a folder.
   1.395 -.P
   1.396 -This was, it was only possible to work in alternation on multiple drafts.
   1.397 -Therefore, the current draft needed to be refiled to a folder and
   1.398 -another one re-using for editing.
   1.399 -Working on multiple drafts at the same time was impossible.
   1.400 -The usual approach of switching to a different MH context did not
   1.401 -change anything.
   1.402 -.P
   1.403 -The draft folder facility exists to
   1.404 -allow true parallel editing of drafts, in a straight forward way.
   1.405 -It was introduced by Marshall T. Rose, already in 1984.
   1.406 -Similar to other new features, the draft folder was inactive by default.
   1.407 -Even in nmh, the highly useful draft folder was not available
   1.408 -out-of-the-box.
   1.409 -At least, Richard Coleman added the man page
   1.410 -.Mp mh-draft (5)
   1.411 -to better document the feature.
   1.412 -.P
   1.413 -Not using the draft folder facility has the single advantage of having
   1.414 -the draft file at a static location.
   1.415 -This is simple in simple cases but the concept does not scale for more
   1.416 -complex cases.
   1.417 -The concept of the draft message is too limited for the problem.
   1.418 -Therefore the draft folder was introduced.
   1.419 -It is the more powerful and more natural concept.
   1.420 -The draft folder is a folder like any other folder in MH.
   1.421 -Its messages can be listed like any other messages.
   1.422 -A draft message is no longer a special case.
   1.423 -Tools do not need special switches to work on the draft message.
   1.424 -Hence corner-cases were removed.
   1.425 -.P
   1.426 -The trivial part of the work was activating the draft folder with a
   1.427 -default name.
   1.428 -I chose the name
   1.429 -.Fn +drafts
   1.430 -for obvious reasons.
   1.431 -In consequence, the command line switches
   1.432 -.Sw -draftfolder
   1.433 -and
   1.434 -.Sw -draftmessage
   1.435 -could be removed.
   1.436 -More difficult but also more improving was updating the tools to the
   1.437 -new concept.
   1.438 -For nearly three decades, the tools needed to support two draft handling
   1.439 -approaches.
   1.440 -By fully switching to the draft folder, the tools could be simplified
   1.441 -by dropping the awkward draft message handling code.
   1.442 -.Sw -draft
   1.443 -switches were removed because operating on a draft message is no longer
   1.444 -special.
   1.445 -It became indistinguishable to operating on any other message.
   1.446 -There is no more need to query the user for draft handling.
   1.447 -It is always possible to add another new draft.
   1.448 -Refiling drafts is without difference to refiling other messages.
   1.449 -All these special cases are gone.
   1.450 -Yet, one draft-related switch remained.
   1.451 -.Pn comp
   1.452 -still has
   1.453 -.Sw -[no]use
   1.454 -for switching between two modes:
   1.455 -.BU
   1.456 -.Sw -use :
   1.457 -Modify an existing draft.
   1.458 -.BU
   1.459 -.Sw -nouse :
   1.460 -Compose a new draft, possibly taking some existing message as a form.
   1.461 -.P
   1.462 -In either case, the behavior of
   1.463 -.Pn comp
   1.464 -is deterministic.
   1.465 -.P
   1.466 -.Pn send
   1.467 -now operates on the current message in the draft folder by default.
   1.468 -As message and folder can both be overridden by specifying them on
   1.469 -the command line, it is possible to send any message in the mail storage
   1.470 -by simply specifying its number and folder.
   1.471 -In contrast to the other tools,
   1.472 -.Pn send
   1.473 -takes the draft folder as its default folder.
   1.474 -.P
   1.475 -Dropping the draft message concept in favor for the draft folder concept,
   1.476 -removed special cases with regular cases.
   1.477 -This simplified the source code of the tools, as well as the concepts.
   1.478 -In mmh, draft management does not break with the MH concepts
   1.479 -but applies them.
   1.480 -Most of the work was already done by Rose in the eighties.
   1.481 -The original improvement in mmh is dropping the draft message approach
   1.482 -completely and thus simplifying the tools, the documentation and the
   1.483 -system as a whole.
   1.484 -Although my part in the draft handling improvement was small,
   1.485 -it was important.
   1.486 -
   1.487 -
   1.488 -
   1.489 -.H2 "Trash Folder
   1.490 -.P
   1.491 -Similar to the situation for drafts is the situation for removed messages.
   1.492 -Historically, a message was ``deleted'' by prepending a specific
   1.493 -\fIbackup prefix\fP, usually the comma character,
   1.494 -to the file name.
   1.495 -The specific message would vanish from MH because only files with
   1.496 -non-digit characters in their name are not treated as messages.
   1.497 -Although files remained in the file system,
   1.498 -the messages were no more visible in MH.
   1.499 -To truly delete them, a maintenance job is needed.
   1.500 -Usually a cron job is installed to delete them after a grace time.
   1.501 -For instance:
   1.502 -.VS
   1.503 -find $HOME/Mail -type f -name ',*' -ctime +7 -delete
   1.504 -VE
   1.505 -In such a setup, the original message can be restored
   1.506 -within the grace time interval by stripping the
   1.507 -the backup prefix from the file name.
   1.508 -But one can not rely on this statement.
   1.509 -If the last message of a folder with six messages (1-6) is removed,
   1.510 -message
   1.511 -.Fn 6 ,
   1.512 -becomes file
   1.513 -.Fn ,6 .
   1.514 -If then a new message enters the same folder, it will be given
   1.515 -the number one higher than the highest existing message.
   1.516 -In this case the message is named
   1.517 -.Fn 6
   1.518 -then.
   1.519 -If this message is removed as well,
   1.520 -then the backup of the former message gets overwritten.
   1.521 -Hence, the ability to restore removed messages does not only depend on
   1.522 -the ``sweeping cron job'' but also on the removing of further messages.
   1.523 -It is undesirable to have such obscure and complex mechanisms.
   1.524 -The user should be given a small set of clear assertions.
   1.525 -``Removed files are restorable within a seven-day grace time.''
   1.526 -is such a clear assertion.
   1.527 -With the addition ``... unless a message with the same name in the
   1.528 -same folder is removed before.'' the statement becomes complex.
   1.529 -A user will hardly be able to keep track of any removal to know
   1.530 -if the assertion still holds true for a specific file.
   1.531 -The the real mechanism is practically obscure to the user.
   1.532 -The consequences of further removals are not obvious.
   1.533 -.P
   1.534 -Further more, the backup files are scattered within the whole mail storage.
   1.535 -This complicates managing them.
   1.536 -It is possible, with help of
   1.537 -.Pn find ,
   1.538 -but everything would be more convenient
   1.539 -if the deleted messages would be collected in one place.
   1.540 -.P
   1.541 -The profile entry
   1.542 -.Pe rmmproc
   1.543 -(previously named
   1.544 -.Pe Delete-Prog )
   1.545 -was introduced very early to improve the situation.
   1.546 -It could be set to any command, which would be executed to removed
   1.547 -the specified messages.
   1.548 -This would override the default action, described above.
   1.549 -Refiling the to-be-removed files to a garbage folder is the usual example.
   1.550 -Nmh's man page
   1.551 -.Mp rmm (1)
   1.552 -proposes to set the
   1.553 -.Pe rmmproc
   1.554 -to
   1.555 -.Cl "refile +d
   1.556 -to move messages to the garbage folder,
   1.557 -.Fn +d ,
   1.558 -instead of renaming them with the backup prefix.
   1.559 -The man page proposes additionally the expunge command
   1.560 -.Cl "rm `mhpath +d all`
   1.561 -to empty the garbage folder.
   1.562 -.P
   1.563 -Removing messages in such a way has advantages.
   1.564 -The mail storage is prevented from being cluttered with removed messages
   1.565 -because they are all collected in one place.
   1.566 -Existing and removed messages are thus separated more strictly.
   1.567 -No backup files are silently overwritten.
   1.568 -Most important is the ability to keep removed messages in the MH domain.
   1.569 -Messages in the trash folder can be listed like those in any other folder.
   1.570 -Deleted messages can be displayed like any other messages.
   1.571 -Restoring a deleted messages can be done with
   1.572 -.Pn refile .
   1.573 -All operations on deleted files are still covered by the MH tools.
   1.574 -The trash folder is just like any other folder in the mail storage.
   1.575 -.P
   1.576 -Similar to the draft folder case, I dropped the old backup prefix approach
   1.577 -in favor for replacing it by the better suiting trash folder system.
   1.578 -Hence,
   1.579 -.Pn rmm
   1.580 -calls
   1.581 -.Pn refile
   1.582 -to move the to-be-removed message to the trash folder,
   1.583 -.Fn +trash
   1.584 -by default.
   1.585 -To sweep it clean, one can use
   1.586 -.Cl "rmm -unlink +trash a" ,
   1.587 -where the
   1.588 -.Sw -unlink
   1.589 -switch causes the files to be unlinked.
   1.590 -.P
   1.591 -Dropping the legacy approach and completely converting to the new approach
   1.592 -simplified the code base.
   1.593 -The relationship between
   1.594 -.Pn rmm
   1.595 -and
   1.596 -.Pn refile
   1.597 -was inverted.
   1.598 -In mmh,
   1.599 -.Pn rmm
   1.600 -invokes
   1.601 -.Pn refile ,
   1.602 -which used to be the other way round.
   1.603 -Yet, the relationship is simpler now.
   1.604 -No more can loops, like described in nmh's man page for
   1.605 -.Mp refile (1),
   1.606 -occur:
   1.607 -.QS
   1.608 -Since
   1.609 -.Pn refile
   1.610 -uses your
   1.611 -.Pe rmmproc
   1.612 -to delete the message, the
   1.613 -.Pe rmmproc
   1.614 -must NOT call
   1.615 -.Pn refile
   1.616 -without specifying
   1.617 -.Sw -normmproc
   1.618 -or you will create an infinite loop.
   1.619 -.QE
   1.620 -.LP
   1.621 -.Pn rmm
   1.622 -either unlinks a message with
   1.623 -.Fu unlink()
   1.624 -or invokes
   1.625 -.Pn refile
   1.626 -to move it to the trash folder.
   1.627 -.Pn refile
   1.628 -does not invoke any tools.
   1.629 -.P
   1.630 -
   1.631 -
   1.632 -
   1.633 -Keeping unused alternative in the code is a bad choice as they likely
   1.634 -gather bugs, by not being constantly tested.
   1.635 -Also, the increased code
   1.636 -size and more conditions crease the maintenance costs.
   1.637 -
   1.638 -By generalizing the message removal in a way that it becomes covered
   1.639 -by the MH concepts makes the whole system more powerful.
   1.640 -
   1.641 -
   1.642 -
   1.643 -.H2 "Path Notations
   1.644 -.P
   1.645 -FIXME! TODO
   1.646 -
   1.647 -
   1.648 -
   1.649 -.H2 "Of One Cast
   1.650 -.P
   1.651 +    Completely reworked the path convertion functions
   1.652 +    Moved everything (from sbr/getfolder.c and sbr/m_maildir.c) into
   1.653 +    sbr/path.c, but actually replaced the code almost completely.
   1.654 +    See h/prototypes.h for the function changes.
   1.655 +    sbr/path.c provides explaining comments on the functions.
   1.656 +    None of them allocates memory automatically.
   1.657 +    
   1.658 +    Additionally:
   1.659 +    - Like for other ``files'', `inc -audit file' places file relative
   1.660 +      to the cwd, not relative to the mh-dir. This is for consistency.
   1.661 +    - Replaced add(foo, NULL) with getcpy(foo), which ist clearer.

     2.1 --- a/intro.roff	Mon Jul 02 23:14:19 2012 +0200
     2.2 +++ b/intro.roff	Tue Jul 03 11:11:12 2012 +0200
     2.3 @@ -165,7 +165,7 @@
     2.4  .VF input/mh-session
     2.5  
     2.6  
     2.7 -.H1 "nmh: Code and Community
     2.8 +.H1 "nmh
     2.9  .P
    2.10  In order to understand the condition, goals and dynamics of a project,
    2.11  one needs to know the reasons behind them.
    2.12 @@ -377,6 +377,7 @@
    2.13  appealing MUA should be removed.
    2.14  This includes the mail submission and mail retrieval facilities.
    2.15  Choice should be reduced to the main options.
    2.16 +All tools should be tightly shaped.
    2.17  .IP "Modernizing
    2.18  Mmh's feature set needs to become more modern.
    2.19  Better support for attachment and digital cryptography should be added.
    2.20 @@ -384,9 +385,10 @@
    2.21  The modern email features need to be readily available, out-of-the-box.
    2.22  On the other hand,
    2.23  bulletin board support and similar obsolete facilities can be dropped out.
    2.24 -Likewise, ancient technologies such as hardcopy terminals
    2.25 -need not to be supported any further.
    2.26 -.IP "Code style
    2.27 +Likewise, ancient technologies should not be supported any further.
    2.28 +The available concepts need to be expanded as far as possible.
    2.29 +A small set of concepts should recur consistently.
    2.30 +.IP "Styling
    2.31  Mmh's source code needs to be updated to modern standards.
    2.32  Standardized library functions should replace non-standard versions
    2.33  whenever possible.
    2.34 @@ -394,8 +396,5 @@
    2.35  Time and space optimizations should to be replaced by
    2.36  clear and readable code.
    2.37  A uniform programming style should prevail.
    2.38 -.IP "Homogeneity
    2.39 -The available concepts need to be expanded as far as possible.
    2.40 -A small set of concepts should recur consistently.
    2.41  The whole system should appear to be of-one-style;
    2.42  it should feel like being cast as one.