On Wed, Feb 17, 1999 at 02:52:36AM -0500, Randall J. Million <[EMAIL PROTECTED]>
wrote:
> > What are the problems that you have with this? It would take just a
> > tiny bit of code to add a "trash_folder" variable, which when set, would
> > receive a copy of deleted messages. But I'm not sure what doesn't work
> > about the above?
>
> 1. You cannot undelete messages and have them removed from the Trash
> folder.
> 2. It is possible to delete a message multiple times (and svae it to the
> Trash folder multiple times). Limited accoutn space made the
> duplicated messages hard to deal with.
Hmm. I guess the time to save the mesags to the trash folder would be
when actually synchronizing the mailbox, then.
> 3. No good way I found (without cron privs) to automatically delete
> messages without entering the Trash folder.
This is (IMHO) beyond the scope of what mutt should be able to do. It
will be easy to delete messages from cron with a find command if you
make the folder a maildir or MH folder, but it will also be easy to do
the same thing from your .login, or from a shell script wrapper around
mutt, or any number of things.
> 4. Takes relatively long time and puts a Saving... Message up.
Hmm. My method would make deleting messages instant, but then
resynchronizing the folder might take a moment longer. But I think this
will be nicer.
> 5. Does not work with the tag-prefix or with thread-delete.
I don't see why it wouldn't work with tag-prefix if your macro is
"s=deleted\n" or whatever. But thread-delete is a good point. This
will all be moot if we do it my way.
Hmm, I wonder how hard this would be to code? Looking at the code a
bit, I come to the conclusion that it would be trivial to do this, but
such an implementation would have the problem that we would sometimes
save a copy of the message to the trash mailbox but then fail to
synchronize the folder. By the time we successfully synchronized the
folder, we would have several copies of the message in the trash. This
is not so bad, since this is just a backup mechanism, and too many is
much better than too few. But it is still a bit ugly. Alternatives are
to do this from within the routines specific to different types of
mailboxes, after we have checked for new messages and dealt with
locking. That would be a bit ugly too. A third alternative would be to
split up the various sync functions into two parts, but I don't know if
this change justifies that. I will think about this a little bit more.
-Daniel
--
Daniel Eisenbud
[EMAIL PROTECTED]
