1.1 --- a/ch03.roff	Sun Apr 22 12:34:14 2012 +0200
     1.2 +++ b/ch03.roff	Sun Apr 22 13:50:35 2012 +0200
     1.3 @@ -118,7 +118,7 @@
     1.4  
     1.5  
     1.6  .H1 "Draft and Trash Folders
     1.7 -.U2 "The Draft Folder
     1.8 +.U2 "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 @@ -175,6 +175,63 @@
    1.13  All theses changes converted special cases to regular cases, thus
    1.14  simplifying the tools and increasing the flexibility.
    1.15  
    1.16 +.U2 "Trash Folder
    1.17 +.P
    1.18 +Similar to the situation for drafts is the situation for removed messages.
    1.19 +Historically, a message was deleted by renaming. A specific
    1.20 +\fIbackup prefix\fP, often comma (\fL,\fP) or hash (\fL#\fP),
    1.21 +being prepended to the file name. Thus, MH wouldn't recognize the file
    1.22 +as a message anymore, as only files whose name consists of digits only
    1.23 +are treated as messages. The removed messages remained as files in the
    1.24 +same directory and needed some maintenance job to truly delete them after
    1.25 +some grace time. Usually, by running a command similar to
    1.26 +.DS
    1.27 +find /home/user/Mail \-ctime +7 \-name ',*' | xargs rm
    1.28 +.DE
    1.29 +in a cron job. Within the grace time interval
    1.30 +the original message could be restored by stripping the
    1.31 +the backup prefix from the file name. If however, the last message of
    1.32 +a folder is been removed \(en say message `\fL6\fP' becomes file
    1.33 +`\fL,6\fP' \(en and a new message enters the same folder, thus the same
    1.34 +numbered being given again \(en in out case `\fL6\fP' \(en, if that one
    1.35 +is removed too, then the backup of the former message gets over written.
    1.36 +Thus, the ability to restore removed messages does not only depend on
    1.37 +the ``sweeping cron job'' but also on the removing of further messages.
    1.38 +This is undesireable, because the real mechanism is hidden from the user
    1.39 +and the concequences of further removals are not always obvious.
    1.40 +Further more, the backup files are scattered within the whole mail
    1.41 +storage, instead of being collected at one place.
    1.42 +.P
    1.43 +To improve the situation, the profile entry \fIrmmproc\fP
    1.44 +(previously named \fIDelete-Prog\fP) was introduced, very early.
    1.45 +It could be set to any command, which would care for the mail removal
    1.46 +instead of taking the default action, described above.
    1.47 +Refiling the to-be-removed files to some wastebin folder was a common
    1.48 +example. Nmh's man page for \fLrmm(1)\fP proposes `\fLrefile +d\fP'
    1.49 +(implemented through a shell alias) and `\fLrm `mhpath +d all`\fP'
    1.50 +the empty the wastebin.
    1.51 +Managing the message removal this way is a sane approach. It keeps
    1.52 +the removed messages in one place, makes it easy to remove the backup
    1.53 +files, and, most important, enables the user to use the tools of MH
    1.54 +itself to operate on the removed messages. One can \fLscan\fP them,
    1.55 +\fLshow\fP them, and restore them with \fLrefile(1)\fP. There's no more
    1.56 +need to use \fLmhpath\fP to switch over from MH tools to Unix tools
    1.57 +\(en MH can do it all itself.
    1.58 +.P
    1.59 +This apporach is matches perfect with the concepts of MH, thus making
    1.60 +it powerful. Hence, I made it the default. And even more, I also
    1.61 +removed the old backup prefix approach, as it is clearly less powerful.
    1.62 +Keeping unused alternative in the code is a bad choice as they likely
    1.63 +gather bugs, by not being constantly tested. Also, the increased code
    1.64 +size and more conditions crease the maintenance costs. By strictly
    1.65 +converting to the trash folder approach, I simplified the code base.
    1.66 +\fLrmm(1)\fP calls \fLrefile(1)\fP internally to move the to-be-removed
    1.67 +message to the trash folder (`\fL+trash\fP' by default). Messages
    1.68 +there can be operated on like on any other message in the storage.
    1.69 +The sweep clean, one can use `\fLrmm \-unlink +trash a\fP', where
    1.70 +the `\fL\-unlink\fP' switch causes the files to be truly unliked instead
    1.71 +of moved to the trash folder.
    1.72 +
    1.73  
    1.74  .H1 "Paths to ...
    1.75  .P