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

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

Reto venit, vidit, dixit 2021-05-12 07:10:13:
> On Tue, May 11, 2021 at 08:48:45AM +0200, Michael J Gruber wrote:
> > If you sync gmail labels to exact copies in different folders then you're not
> > holding it right, sorry ;)
> 
> > 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).
> 
> Better is always a relative term. I prefer a standardized protocol over some
> homebrew stuff.
 
???

The question is whether you talk Gmail API to Gmail or IMAP to Gmail.
What is homebrew here?

> > 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.
> 
> It's not only gmail, really any IMAP server.
> If you have a message in multiple folders at the same time (which is entirely
> reasonable, think "todo" + where it actually should go after processing).
> They all have the same message ID.
> 
> Only because you delete the copy from todo doesn't mean that you want it gone
> from other places as well.
> 
> Sure, you could move instead of copying...
> But that means that you may now need to hunt through multiple folders instead of
> being able to grab the message from the actual mbox it should be in.
> 
> IMAP doesn't impose a workflow, just because yours happens to be a certain way
> doesn't make it the gold standard ;)

Exactly, those arguments are turning into the ridiculous.

The point is that folders are neither labels nor tags.

You use an IMAP-sync tool to bolt on the tag concept onto a folder
structure. This creates problems which only the sync tool can solve, not
the indexer (notmuch), because it is the sync tool which translates the
IMAP folder structure (and IMAP flags) into a maildir store (and maildir
flags).

Indeed, IMAP even has extended flags but support on the IMAP client side is
typically suboptimal, so people don't use them at all or not to a great
extent; they would be a good match for notmuch tags.

Now, the only point at which notmuch is involved is indexing the
maildir. This includes synchronizing the maildir flags to notmuch tags -
and currently notmuch fails to synchronize one flag from the maildir
standard. Felipe and I suggest to reinstate that.

Note that since notmuch identifies messages by mid and one mid can correspond
to multiple files (e.g. due to folder copies, list copies, sent/cc) it
has to decide which file to index. Currently, notmuch assumes the
content to be identical (it indexes the content of one file) but takes a
union of reference headers and flags from all files.

"Union of [boolean] flags" is the real issue here: AND or OR? Currently
it's OR for all flags, and this happens to work for most workflows
because the tag "unread" does not correspond to a maildir flag - rather,
maildir has "S" (seen) so that OR of seen maildir flags decides whether
notmuch does not tag the message "unread".

Notice how this imposes a "gold standard workflow" on how you use 
read/unread on multiple copies of the same message?
On the IMAP side, marking 1 copy of your message read or unread does not
change the other one (much to the dismay of users who want to use
automatic filters for sorting). Sync that (mbsync or such) two your
maildir store and you one message file with "S", the other one without.
Index with notmuch and *the* message will not be "unread" (even though
one copy is not "Seen" per maildir flag). Toggle the "unread" tag with
notmuch and all copies or none will have "S"; syncing back to the IMAP
side will correspondingly mark all copies read or all unread.

So, unless you force notmuch to sync tags back to maildir flags (e.g. by
toggling them) it does not even mark all copies S even though the tag
(absence of "unread") would warrant that.

But whether this is the correct representation of "S" as "not unread"
really depends on your workflow, that is your usage of copies und your
usage of that flag. And yet, notmuch does sync it rather than bailing
out because it requires a decision.

In the very same way as marking one copy read marks all read (on the
notmuch side as opposed to the IMAP side), why shouldn't the same be
true for deleted? Because users with an IMAP mindset will complain about
one but not the other, even though they are analogous...

That's why I suggest the softer approach of treating the union of "T" as
and AND: tag a message as "trashed" if all its copies have maildir flag
"T". That way, users with multiple copies don't shoot themselves in the
foot (and don't complain to us). If you tag a message as "trashed", all
copies get "T", of course. This should give the best user experience:
Once an IMAP server or IMAP sync tool expunges "T" messages notmuch will
merely notices a missing file, unless it was the last one in which case
it notices message deletion (and in which case it showed "trashed"
before because it was the only one and had "T").

But really, if you use folders as a tag substitute you should think
about moving files to a trash folder rather than marking them trashed,
in which case we don't have to worry about "T". (Notmuch's lack of
T-syncing made me do this and it works fine.)

Michael