[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: delete no longer working
Martin Fouts <fouts@null.net> writes:
> > The problem with EXPUNGE is that you can't be sure of what you
> > expunge, if the \Deleted flag should have any user-visible
> > semantics at all you could have articles marked \Deleted but keep
> > them in the mailbox. Then EXPUNGE can't be used, hence we cannot
> > delete articles at all.
>
> I've just scanned RFC 2060 for discussion of the \Deleted flag, and it
> seems to me that it would be very dangerous to assign any user-visible
> semantic to \Deleted other than 'will-go-away-when-expunged'.
Then the question is wether we should EXPUNGE on group exit? I guess
we couldn't easily do it anywhere else so I've changed the code back
to the old behaviour.
(Patch attached if you can't wait for 0.3.28)
> It seems to have been designed to work in a way similar to the
> delete option on early Unix mailers -- or, for that matter, the way
> dired works -- flags are set to indicate that the operation *should*
> be performed eventually as a result of a specific 'do-it' command.
Yup. But this behaviour assumes, I think, that there is only one
client setting those "process" flags. The \Deleted flag should IMHO be
session specific (and not mailbox specific), so the server should keep
different \Deleted flag's for different server connections and on
EXPUNGE only delete articles marked \Deleted in that session.
For, dare I say, 100 % of normal user activites this would result in
the same articles being deleted, but I could easily construct a
scenario in which it didn't. O well, I'm babbling again.
/s
Index: nnimap.el
===================================================================
RCS file: /home/radford/src/cvs/nnimap/nnimap.el,v
retrieving revision 1.51
retrieving revision 1.52
diff -r1.51 -r1.52
653,654c653,654
< ;; Close her up. We don't necessarily have to do this.
< (when (imap-unselect-folder group)
---
> ;; Expunge and close.
> (when (imap-expunge-close-folder group)