docs/master: discussion.roff comparison

comparison discussion.roff @ 130:0b9aa74ced4d

Reworked the text on the Trash Folder.

author	markus schnalke <meillo@marmaro.de>
date	Mon, 02 Jul 2012 23:14:19 +0200
parents	01af3c0dfe7b
children	7c741bc8f719

comparison

equal deleted inserted replaced

-:01af3c0dfe7b
+:0b9aa74ced4d
 .H2 "Trash Folder
 .P
 Similar to the situation for drafts is the situation for removed messages.
-Historically, a message was deleted by renaming.
+Historically, a message was ``deleted'' by prepending a specific
-A specific
+\fIbackup prefix\fP, usually the comma character,
-\fIbackup prefix\fP, often comma (\c
+to the file name.
-.Fn , )
+The specific message would vanish from MH because only files with
-or hash (\c
+non-digit characters in their name are not treated as messages.
-.Fn # ),
+Although files remained in the file system,
-being prepended to the file name.
+the messages were no more visible in MH.
-Thus, MH wouldn't recognize the file
+To truly delete them, a maintenance job is needed.
-as a message anymore, as only files whose name consists of digits only
+Usually a cron job is installed to delete them after a grace time.
-are treated as messages.
+For instance:
-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
 .VS
-find /home/user/Mail -ctime +7 -name ',*' | xargs rm
+find $HOME/Mail -type f -name ',*' -ctime +7 -delete
 VE
-in a cron job.
+In such a setup, the original message can be restored
-Within the grace time interval
+within the grace time interval by stripping the
-the original message could be restored by stripping the
 the backup prefix from the file name.
-If however, the last message of
+But one can not rely on this statement.
-a folder is been removed \(en say message
+If the last message of a folder with six messages (1-6) is removed,
+message
+.Fn 6 ,
+becomes file
+.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
-becomes file
+then.
-.Fn ,6
+If this message is removed as well,
-\(en and a new message enters the same folder, thus the same
+then the backup of the former message gets overwritten.
-numbered being given again \(en in our case
+Hence, the ability to restore removed messages does not only depend on
-.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
 the ``sweeping cron job'' but also on the removing of further messages.
-This is undesirable, because the real mechanism is hidden from the user
+It is undesirable to have such obscure and complex mechanisms.
-and the consequences of further removals are not always obvious.
+The user should be given a small set of clear assertions.
-Further more, the backup files are scattered within the whole mail
+``Removed files are restorable within a seven-day grace time.''
-storage, instead of being collected at one place.
+is such a clear assertion.
-.P
+With the addition ``... unless a message with the same name in the
-To improve the situation, the profile entry
+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
+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.
+was introduced very early to improve the situation.
-It could be set to any command, which would care for the mail removal
+It could be set to any command, which would be executed to removed
-instead of taking the default action, described above.
+the specified messages.
-Refiling the to-be-removed files to some garbage folder was a common
+This would override the default action, described above.
-example.
+Refiling the to-be-removed files to a garbage folder is the usual example.
 Nmh's man page
-.Mp rmm(1)
+.Mp rmm (1)
-proposes
+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.
+to empty the garbage folder.
-Managing the message removal this way is a sane approach.
+.P
-It keeps
+Removing messages in such a way has advantages.
-the removed messages in one place, makes it easy to remove the backup
+The mail storage is prevented from being cluttered with removed messages
-files, and, most important, enables the user to use the tools of MH
+because they are all collected in one place.
-itself to operate on the removed messages.
+Existing and removed messages are thus separated more strictly.
-One can
+No backup files are silently overwritten.
-.Pn scan
+Most important is the ability to keep removed messages in the MH domain.
-them,
+Messages in the trash folder can be listed like those in any other folder.
-.Pn show
+Deleted messages can be displayed like any other messages.
-them, and restore them with
+Restoring a deleted messages can be done with
 .Pn refile .
-There's no more
+All operations on deleted files are still covered by the MH tools.
-need to use
+The trash folder is just like any other folder in the mail storage.
-.Pn mhpath
+.P
-to switch over from MH tools to Unix tools \(en MH can do it all itself.
+Similar to the draft folder case, I dropped the old backup prefix approach
-.P
+in favor for replacing it by the better suiting trash folder system.
-This approach matches perfect with the concepts of MH, thus making
+Hence,
-it powerful.
+.Pn rmm
-Hence, I made it the default.
+calls
-And even more, I also
+.Pn refile
-removed the old backup prefix approach, as it is clearly less powerful.
+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
+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.
+By generalizing the message removal in a way that it becomes covered
-.Pn rmm
+by the MH concepts makes the whole system more powerful.
-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.
 .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
 .P

Mercurial > docs > master

comparison discussion.roff @ 130:0b9aa74ced4d