On Wed, Feb 17, 1999 at 12:57:52AM -0800, Daniel Eisenbud 
<[EMAIL PROTECTED]> wrote:
> 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.

Something about this that I somehow failed to consider is that this will
save a copy of a message to the trash folder when you are just trying to
copy the message to another mailbox, rather than delete it.  Maybe we
need a flag which gets set when the message is succesfully saved
somewhere?

[...]
> 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.

For the moment, I did this the easy way.  It should work fine, but
if you have a lot of new mail arriving, you may get multiple copies of
deleted mails in the trash folder.  Also, as stated above, a copy of all
copied mail will also end up in the trash folder.  If there is
sufficient interest in this patch, I plan to fix both of these things,
though.

Oh yeah, the variable name is $trash_folder.  And no, it isn't yet smart
enough to actually delete the messages when you're in the trash folder,
so you'll need a folder-hook if you want to do that.  I plan on fixing
that, too.

So be cautious with this patch.  I can't see how it could do anything
worse than failing to save your deleted messages to the trash, or
causing a coredump.  It should do neither of those things, but it's late
at night, so I might have missed something obvious.

After applying the patch, you will have to run "make clean" before
recompiling mutt, if you've already compiled in that source tree before.

-Daniel

-- 
Daniel Eisenbud
[EMAIL PROTECTED]
diff -durpN mutt-0.95.3/globals.h mutt-0.95.3.trashfolder/globals.h
--- mutt-0.95.3/globals.h       Thu Jan  7 01:14:40 1999
+++ mutt-0.95.3.trashfolder/globals.h   Wed Feb 17 01:42:42 1999
@@ -77,6 +77,7 @@ WHERE char *StChars;
 WHERE char *Status;
 WHERE char *Tempdir;
 WHERE char *Tochars;
+WHERE char *TrashFolder;
 WHERE char *Username;
 WHERE char *Visual;
 
diff -durpN mutt-0.95.3/init.h mutt-0.95.3.trashfolder/init.h
--- mutt-0.95.3/init.h  Wed Feb 10 08:20:11 1999
+++ mutt-0.95.3.trashfolder/init.h      Wed Feb 17 01:42:06 1999
@@ -266,6 +266,7 @@ struct option_t MuttVars[] = {
   { "tilde",           DT_BOOL, R_PAGER, OPTTILDE, 0 },
   { "timeout",         DT_NUM,  R_NONE, UL &Timeout, 600 },
   { "tmpdir",          DT_PATH, R_NONE, UL &Tempdir, 0 },
+  { "trash_folder",    DT_PATH, R_NONE, UL &TrashFolder, UL "" },
   { "to_chars",                DT_STR,  R_BOTH, UL &Tochars, UL " +TCF" },
   { "use_8bitmime",    DT_BOOL, R_NONE, OPTUSE8BITMIME, 0 },
   { "use_domain",      DT_BOOL, R_NONE, OPTUSEDOMAIN, 1 },
diff -durpN mutt-0.95.3/mx.c mutt-0.95.3.trashfolder/mx.c
--- mutt-0.95.3/mx.c    Tue Feb  9 15:53:40 1999
+++ mutt-0.95.3.trashfolder/mx.c        Wed Feb 17 02:55:12 1999
@@ -946,6 +946,7 @@ void mx_update_tables(CONTEXT *ctx, int 
 int mx_sync_mailbox (CONTEXT *ctx)
 {
   int rc, i;
+  CONTEXT *trash;
 
   if (ctx->dontwrite)
   {
@@ -988,8 +989,33 @@ int mx_sync_mailbox (CONTEXT *ctx)
        ctx->hdrs[i]->deleted = 0;
       ctx->deleted = 0;
     }
-  }
+    else if (TrashFolder && *TrashFolder)
+    {
+      rc = 0;
+      mutt_message (_("Copying deleted to %s..."), TrashFolder);
+      trash = mx_open_mailbox (TrashFolder, M_APPEND, NULL);
+      if (trash)
+      {
+       for (i = 0; i < ctx->msgcount && !rc; i++)
+       {
+         if (ctx->hdrs[i]->deleted)
+           rc = mutt_append_message (trash, ctx, ctx->hdrs[i], 0, CH_UPDATE_LEN);
+       }
 
+       mx_close_mailbox (trash);
+       safe_free ((void **) &trash);
+      }
+      else
+       rc = -1;
+
+      if (rc)
+      {
+       mutt_error (_("Could not copy deleted to %s"), TrashFolder);
+       return (-1);
+      }
+    }
+  }
+ 
   if ((rc = sync_mailbox (ctx)) == 0)
   {
     mutt_message (_("%d kept, %d deleted."), ctx->msgcount - ctx->deleted,

Reply via email to