--- a/discussion.roff	Mon Jul 02 17:59:21 2012 +0200
+++ b/discussion.roff	Mon Jul 02 23:14:19 2012 +0200
@@ -3477,113 +3477,161 @@
 .H2 "Trash Folder
 .P
 Similar to the situation for drafts is the situation for removed messages.
-Historically, a message was deleted by renaming.
-A specific
-\fIbackup prefix\fP, often comma (\c
-.Fn , )
-or hash (\c
-.Fn # ),
-being prepended to the file name.
-Thus, MH wouldn't recognize the file
-as a message anymore, as only files whose name consists of digits only
-are treated as messages.
-The removed messages remained as files in the
-same directory and needed some maintenance job to truly delete them after
-some grace time.
-Usually, by running a command similar to
+Historically, a message was ``deleted'' by prepending a specific
+\fIbackup prefix\fP, usually the comma character,
+to the file name.
+The specific message would vanish from MH because only files with
+non-digit characters in their name are not treated as messages.
+Although files remained in the file system,
+the messages were no more visible in MH.
+To truly delete them, a maintenance job is needed.
+Usually a cron job is installed to delete them after a grace time.
+For instance:
 .VS
-find /home/user/Mail -ctime +7 -name ',*' | xargs rm
+find $HOME/Mail -type f -name ',*' -ctime +7 -delete
 VE
-in a cron job.
-Within the grace time interval
-the original message could be restored by stripping the
+In such a setup, the original message can be restored
+within the grace time interval by stripping the
 the backup prefix from the file name.
-If however, the last message of
-a folder is been removed \(en say message
-.Fn 6
+But one can not rely on this statement.
+If the last message of a folder with six messages (1-6) is removed,
+message
+.Fn 6 ,
 becomes file
-.Fn ,6
-\(en and a new message enters the same folder, thus the same
-numbered being given again \(en in our case
+.Fn ,6 .
+If then a new message enters the same folder, it will be given
+the number one higher than the highest existing message.
+In this case the message is named
 .Fn 6
-\(en, if that one
-is removed too, then the backup of the former message gets overwritten.
-Thus, the ability to restore removed messages does not only depend on
+then.
+If this message is removed as well,
+then the backup of the former message gets overwritten.
+Hence, the ability to restore removed messages does not only depend on
 the ``sweeping cron job'' but also on the removing of further messages.
-This is undesirable, because the real mechanism is hidden from the user
-and the consequences of further removals are not always obvious.
-Further more, the backup files are scattered within the whole mail
-storage, instead of being collected at one place.
+It is undesirable to have such obscure and complex mechanisms.
+The user should be given a small set of clear assertions.
+``Removed files are restorable within a seven-day grace time.''
+is such a clear assertion.
+With the addition ``... unless a message with the same name in the
+same folder is removed before.'' the statement becomes complex.
+A user will hardly be able to keep track of any removal to know
+if the assertion still holds true for a specific file.
+The the real mechanism is practically obscure to the user.
+The consequences of further removals are not obvious.
 .P
-To improve the situation, the profile entry
+Further more, the backup files are scattered within the whole mail storage.
+This complicates managing them.
+It is possible, with help of
+.Pn find ,
+but everything would be more convenient
+if the deleted messages would be collected in one place.
+.P
+The profile entry
 .Pe rmmproc
 (previously named
 .Pe Delete-Prog )
-was introduced, very early.
-It could be set to any command, which would care for the mail removal
-instead of taking the default action, described above.
-Refiling the to-be-removed files to some garbage folder was a common
-example.
+was introduced very early to improve the situation.
+It could be set to any command, which would be executed to removed
+the specified messages.
+This would override the default action, described above.
+Refiling the to-be-removed files to a garbage folder is the usual example.
 Nmh's man page
-.Mp rmm(1)
-proposes
+.Mp rmm (1)
+proposes to set the
+.Pe rmmproc
+to
 .Cl "refile +d
-to move messages to the garbage folder and
+to move messages to the garbage folder,
+.Fn +d ,
+instead of renaming them with the backup prefix.
+The man page proposes additionally the expunge command
 .Cl "rm `mhpath +d all`
-the empty the garbage folder.
-Managing the message removal this way is a sane approach.
-It keeps
-the removed messages in one place, makes it easy to remove the backup
-files, and, most important, enables the user to use the tools of MH
-itself to operate on the removed messages.
-One can
-.Pn scan
-them,
-.Pn show
-them, and restore them with
+to empty the garbage folder.
+.P
+Removing messages in such a way has advantages.
+The mail storage is prevented from being cluttered with removed messages
+because they are all collected in one place.
+Existing and removed messages are thus separated more strictly.
+No backup files are silently overwritten.
+Most important is the ability to keep removed messages in the MH domain.
+Messages in the trash folder can be listed like those in any other folder.
+Deleted messages can be displayed like any other messages.
+Restoring a deleted messages can be done with
 .Pn refile .
-There's no more
-need to use
-.Pn mhpath
-to switch over from MH tools to Unix tools \(en MH can do it all itself.
+All operations on deleted files are still covered by the MH tools.
+The trash folder is just like any other folder in the mail storage.
+.P
+Similar to the draft folder case, I dropped the old backup prefix approach
+in favor for replacing it by the better suiting trash folder system.
+Hence,
+.Pn rmm
+calls
+.Pn refile
+to move the to-be-removed message to the trash folder,
+.Fn +trash
+by default.
+To sweep it clean, one can use
+.Cl "rmm -unlink +trash a" ,
+where the
+.Sw -unlink
+switch causes the files to be unlinked.
 .P
-This approach matches perfect with the concepts of MH, thus making
-it powerful.
-Hence, I made it the default.
-And even more, I also
-removed the old backup prefix approach, as it is clearly less powerful.
+Dropping the legacy approach and completely converting to the new approach
+simplified the code base.
+The relationship between
+.Pn rmm
+and
+.Pn refile
+was inverted.
+In mmh,
+.Pn rmm
+invokes
+.Pn refile ,
+which used to be the other way round.
+Yet, the relationship is simpler now.
+No more can loops, like described in nmh's man page for
+.Mp refile (1),
+occur:
+.QS
+Since
+.Pn refile
+uses your
+.Pe rmmproc
+to delete the message, the
+.Pe rmmproc
+must NOT call
+.Pn refile
+without specifying
+.Sw -normmproc
+or you will create an infinite loop.
+.QE
+.LP
+.Pn rmm
+either unlinks a message with
+.Fu unlink()
+or invokes
+.Pn refile
+to move it to the trash folder.
+.Pn refile
+does not invoke any tools.
+.P
+
+
+
 Keeping unused alternative in the code is a bad choice as they likely
 gather bugs, by not being constantly tested.
 Also, the increased code
 size and more conditions crease the maintenance costs.
-By strictly
-converting to the trash folder approach, I simplified the code base.
-.Pn rmm
-calls
-.Pn refile
-internally to move the to-be-removed
-message to the trash folder (\c
-.Fn +trash
-by default).
-Messages
-there can be operated on like on any other message in the storage.
-The sweep clean, one can use
-.Cl "rmm -unlink +trash a" ,
-where the
-.Sw -unlink
-switch causes the files to be truly unliked instead
-of moved to the trash folder.
+
+By generalizing the message removal in a way that it becomes covered
+by the MH concepts makes the whole system more powerful.
+
 
 
 .H2 "Path Notations
 .P
-foo
-
+FIXME! TODO
 
-.H2 "MIME Integration
-.P
-user-visible access to whole messages and MIME parts are inherently
-different
 
 
 .H2 "Of One Cast