Re: Is there a reason why the trashed flag is not synced?

[Michael J Gruber <git@grubix.eu>]

Reto venit, vidit, dixit 2021-05-11 08:23:21:
> On Mon, May 10, 2021 at 03:31:52PM +0200, Michael J Gruber wrote:
> > Deleting by chance is more harmful, yes. But is it more typical to clear
> > out duplicate files using "T" or to delete a message (i.e. all it's file
> > copies)?
> 
> You have to be a bit careful here... imap is a relatively strange protocol.
> Consider a provider like gmail that uses a label system over normal imap folders.
> If you assign a message "inbox" and "vacation" and maybe "archive" and then want
> to remove the message from inbox and vacation folders you execute delete instructions.
> That however, certainly shouldn't propagate to the "archive" copy.
> 
> So I'd argue that in fact no, what you mention is not the "typical" thing to do.
> At least not with those providers.
> Not all MUAs behave the same in regards to whether or not they set the trash flag
> first.
> Yes, you can tell neomutt to do almost anything, but if setting the Trash flag
> on one message starts deleting all other copies I'd be very much surprised.

If you sync gmail labels to exact copies in different folders then you're not
holding it right, sorry ;)

Gmail does not "execute a delete instruction" when it removes a label
from a message, and if you sync 1 e-mail to several copies with the same
message id then they are in fact not copies but identical from the point
of view of any programme that identifies messages by message id - such
as notmuch.

Gmail is not an IMAP service; it has an IMAP API which exposes labels as
folders, with all the caveats which this implies. That's why there are
better ways to sync Gmail with a notmuch mail store (gmailieer).

I don't think notmuch should break its design principle (1 message id, 1
message) just to work around a problem caused by a wrong sync procedure:
that "delete instruction" is a result (merely: artifact) of speaking IMAP to Gmail.

Michael