1.1 --- a/discussion.roff	Mon Jul 02 17:59:21 2012 +0200
     1.2 +++ b/discussion.roff	Mon Jul 02 23:14:19 2012 +0200
     1.3 @@ -3477,114 +3477,162 @@
     1.4  .H2 "Trash Folder
     1.5  .P
     1.6  Similar to the situation for drafts is the situation for removed messages.
     1.7 -Historically, a message was deleted by renaming.
     1.8 -A specific
     1.9 -\fIbackup prefix\fP, often comma (\c
    1.10 -.Fn , )
    1.11 -or hash (\c
    1.12 -.Fn # ),
    1.13 -being prepended to the file name.
    1.14 -Thus, MH wouldn't recognize the file
    1.15 -as a message anymore, as only files whose name consists of digits only
    1.16 -are treated as messages.
    1.17 -The removed messages remained as files in the
    1.18 -same directory and needed some maintenance job to truly delete them after
    1.19 -some grace time.
    1.20 -Usually, by running a command similar to
    1.21 +Historically, a message was ``deleted'' by prepending a specific
    1.22 +\fIbackup prefix\fP, usually the comma character,
    1.23 +to the file name.
    1.24 +The specific message would vanish from MH because only files with
    1.25 +non-digit characters in their name are not treated as messages.
    1.26 +Although files remained in the file system,
    1.27 +the messages were no more visible in MH.
    1.28 +To truly delete them, a maintenance job is needed.
    1.29 +Usually a cron job is installed to delete them after a grace time.
    1.30 +For instance:
    1.31  .VS
    1.32 -find /home/user/Mail -ctime +7 -name ',*' | xargs rm
    1.33 +find $HOME/Mail -type f -name ',*' -ctime +7 -delete
    1.34  VE
    1.35 -in a cron job.
    1.36 -Within the grace time interval
    1.37 -the original message could be restored by stripping the
    1.38 +In such a setup, the original message can be restored
    1.39 +within the grace time interval by stripping the
    1.40  the backup prefix from the file name.
    1.41 -If however, the last message of
    1.42 -a folder is been removed \(en say message
    1.43 +But one can not rely on this statement.
    1.44 +If the last message of a folder with six messages (1-6) is removed,
    1.45 +message
    1.46 +.Fn 6 ,
    1.47 +becomes file
    1.48 +.Fn ,6 .
    1.49 +If then a new message enters the same folder, it will be given
    1.50 +the number one higher than the highest existing message.
    1.51 +In this case the message is named
    1.52  .Fn 6
    1.53 -becomes file
    1.54 -.Fn ,6
    1.55 -\(en and a new message enters the same folder, thus the same
    1.56 -numbered being given again \(en in our case
    1.57 -.Fn 6
    1.58 -\(en, if that one
    1.59 -is removed too, then the backup of the former message gets overwritten.
    1.60 -Thus, the ability to restore removed messages does not only depend on
    1.61 +then.
    1.62 +If this message is removed as well,
    1.63 +then the backup of the former message gets overwritten.
    1.64 +Hence, the ability to restore removed messages does not only depend on
    1.65  the ``sweeping cron job'' but also on the removing of further messages.
    1.66 -This is undesirable, because the real mechanism is hidden from the user
    1.67 -and the consequences of further removals are not always obvious.
    1.68 -Further more, the backup files are scattered within the whole mail
    1.69 -storage, instead of being collected at one place.
    1.70 +It is undesirable to have such obscure and complex mechanisms.
    1.71 +The user should be given a small set of clear assertions.
    1.72 +``Removed files are restorable within a seven-day grace time.''
    1.73 +is such a clear assertion.
    1.74 +With the addition ``... unless a message with the same name in the
    1.75 +same folder is removed before.'' the statement becomes complex.
    1.76 +A user will hardly be able to keep track of any removal to know
    1.77 +if the assertion still holds true for a specific file.
    1.78 +The the real mechanism is practically obscure to the user.
    1.79 +The consequences of further removals are not obvious.
    1.80  .P
    1.81 -To improve the situation, the profile entry
    1.82 +Further more, the backup files are scattered within the whole mail storage.
    1.83 +This complicates managing them.
    1.84 +It is possible, with help of
    1.85 +.Pn find ,
    1.86 +but everything would be more convenient
    1.87 +if the deleted messages would be collected in one place.
    1.88 +.P
    1.89 +The profile entry
    1.90  .Pe rmmproc
    1.91  (previously named
    1.92  .Pe Delete-Prog )
    1.93 -was introduced, very early.
    1.94 -It could be set to any command, which would care for the mail removal
    1.95 -instead of taking the default action, described above.
    1.96 -Refiling the to-be-removed files to some garbage folder was a common
    1.97 -example.
    1.98 +was introduced very early to improve the situation.
    1.99 +It could be set to any command, which would be executed to removed
   1.100 +the specified messages.
   1.101 +This would override the default action, described above.
   1.102 +Refiling the to-be-removed files to a garbage folder is the usual example.
   1.103  Nmh's man page
   1.104 -.Mp rmm(1)
   1.105 -proposes
   1.106 +.Mp rmm (1)
   1.107 +proposes to set the
   1.108 +.Pe rmmproc
   1.109 +to
   1.110  .Cl "refile +d
   1.111 -to move messages to the garbage folder and
   1.112 +to move messages to the garbage folder,
   1.113 +.Fn +d ,
   1.114 +instead of renaming them with the backup prefix.
   1.115 +The man page proposes additionally the expunge command
   1.116  .Cl "rm `mhpath +d all`
   1.117 -the empty the garbage folder.
   1.118 -Managing the message removal this way is a sane approach.
   1.119 -It keeps
   1.120 -the removed messages in one place, makes it easy to remove the backup
   1.121 -files, and, most important, enables the user to use the tools of MH
   1.122 -itself to operate on the removed messages.
   1.123 -One can
   1.124 -.Pn scan
   1.125 -them,
   1.126 -.Pn show
   1.127 -them, and restore them with
   1.128 +to empty the garbage folder.
   1.129 +.P
   1.130 +Removing messages in such a way has advantages.
   1.131 +The mail storage is prevented from being cluttered with removed messages
   1.132 +because they are all collected in one place.
   1.133 +Existing and removed messages are thus separated more strictly.
   1.134 +No backup files are silently overwritten.
   1.135 +Most important is the ability to keep removed messages in the MH domain.
   1.136 +Messages in the trash folder can be listed like those in any other folder.
   1.137 +Deleted messages can be displayed like any other messages.
   1.138 +Restoring a deleted messages can be done with
   1.139  .Pn refile .
   1.140 -There's no more
   1.141 -need to use
   1.142 -.Pn mhpath
   1.143 -to switch over from MH tools to Unix tools \(en MH can do it all itself.
   1.144 +All operations on deleted files are still covered by the MH tools.
   1.145 +The trash folder is just like any other folder in the mail storage.
   1.146  .P
   1.147 -This approach matches perfect with the concepts of MH, thus making
   1.148 -it powerful.
   1.149 -Hence, I made it the default.
   1.150 -And even more, I also
   1.151 -removed the old backup prefix approach, as it is clearly less powerful.
   1.152 +Similar to the draft folder case, I dropped the old backup prefix approach
   1.153 +in favor for replacing it by the better suiting trash folder system.
   1.154 +Hence,
   1.155 +.Pn rmm
   1.156 +calls
   1.157 +.Pn refile
   1.158 +to move the to-be-removed message to the trash folder,
   1.159 +.Fn +trash
   1.160 +by default.
   1.161 +To sweep it clean, one can use
   1.162 +.Cl "rmm -unlink +trash a" ,
   1.163 +where the
   1.164 +.Sw -unlink
   1.165 +switch causes the files to be unlinked.
   1.166 +.P
   1.167 +Dropping the legacy approach and completely converting to the new approach
   1.168 +simplified the code base.
   1.169 +The relationship between
   1.170 +.Pn rmm
   1.171 +and
   1.172 +.Pn refile
   1.173 +was inverted.
   1.174 +In mmh,
   1.175 +.Pn rmm
   1.176 +invokes
   1.177 +.Pn refile ,
   1.178 +which used to be the other way round.
   1.179 +Yet, the relationship is simpler now.
   1.180 +No more can loops, like described in nmh's man page for
   1.181 +.Mp refile (1),
   1.182 +occur:
   1.183 +.QS
   1.184 +Since
   1.185 +.Pn refile
   1.186 +uses your
   1.187 +.Pe rmmproc
   1.188 +to delete the message, the
   1.189 +.Pe rmmproc
   1.190 +must NOT call
   1.191 +.Pn refile
   1.192 +without specifying
   1.193 +.Sw -normmproc
   1.194 +or you will create an infinite loop.
   1.195 +.QE
   1.196 +.LP
   1.197 +.Pn rmm
   1.198 +either unlinks a message with
   1.199 +.Fu unlink()
   1.200 +or invokes
   1.201 +.Pn refile
   1.202 +to move it to the trash folder.
   1.203 +.Pn refile
   1.204 +does not invoke any tools.
   1.205 +.P
   1.206 +
   1.207 +
   1.208 +
   1.209  Keeping unused alternative in the code is a bad choice as they likely
   1.210  gather bugs, by not being constantly tested.
   1.211  Also, the increased code
   1.212  size and more conditions crease the maintenance costs.
   1.213 -By strictly
   1.214 -converting to the trash folder approach, I simplified the code base.
   1.215 -.Pn rmm
   1.216 -calls
   1.217 -.Pn refile
   1.218 -internally to move the to-be-removed
   1.219 -message to the trash folder (\c
   1.220 -.Fn +trash
   1.221 -by default).
   1.222 -Messages
   1.223 -there can be operated on like on any other message in the storage.
   1.224 -The sweep clean, one can use
   1.225 -.Cl "rmm -unlink +trash a" ,
   1.226 -where the
   1.227 -.Sw -unlink
   1.228 -switch causes the files to be truly unliked instead
   1.229 -of moved to the trash folder.
   1.230 +
   1.231 +By generalizing the message removal in a way that it becomes covered
   1.232 +by the MH concepts makes the whole system more powerful.
   1.233 +
   1.234  
   1.235  
   1.236  .H2 "Path Notations
   1.237  .P
   1.238 -foo
   1.239 +FIXME! TODO
   1.240  
   1.241  
   1.242 -.H2 "MIME Integration
   1.243 -.P
   1.244 -user-visible access to whole messages and MIME parts are inherently
   1.245 -different
   1.246 -
   1.247  
   1.248  .H2 "Of One Cast
   1.249  .P