Working with gmail

[Gesh <ge...@ge...>]

Hi,
I'm struggling a bit to set mbsync up to sync some gmail accounts.
I wanted to pull out the inbox, outbox and draft folders to be synced more
frequently, but mbsync complains that eg
> Error: channel gesh-iobox: near side box [Gmail]/Sent Mail cannot be opened.
Investigating suggests I need to escape the name of the near-side box by writing
it as
> Channel gesh-iobox-sent
> Far :gesh-remote:"[Gmail]/Sent Mail"
> Near :gesh-local:"\\[Gmail\\]/Sent Mail"
>
> Channel gesh-iobox-drafts
> ...
or
> Channel gesh-iobox
> Far :gesh-remote:
> Near :gesh-local:
> Patterns INBOX "\\[Gmail\\]/Sent Mail" "\\[Gmail\\]/Drafts"
which works, but is ugly and does not match the suggestions I see elsewhere
online. This raises
Q1: Is there a nicer way of writing this?

A tangential bug I had here is that for some reason, syncing messages meant that
a bunch of them had their delivery times reset *on the server end*, so that when
my phone went to check for email, it moved my huge backlog to the end of history
where I was forced to handle it. I've set
> CopyArrivalDate yes
and hope it fixes things -- I've deleted the old messages, so I probably will
only be able to report negative results here.
Q2: Has anyone else encountered this?

Finally, the mismatch between the local maildirs (using folders and notmuch
tags) and the remote situation (using labels) is making me a little twitchy.
For one, this means I'm duplicating syncs (though I tend not to multilabel, so
this is less bad than it seems). For another, this means my notmuch tags are
limited to my computer, and won't eg sync to my phone.
The canonical solution for this appears to be to use programs like lieer[2] to
use Google's APIs directly, but those tend to be overspecialized and
overwrought.
An alternative concept would be to patch mbsync so it stores/updates IMAP
extension attributes. Eg for Gmail[1], a configuration such as
> IMAPAccount ...
> StoreAttr X-GM-MSGID X-GM-THRID X-GM-LABELS
> UpdateAttr X-GM-LABELS
would have the effect of adding those three headers to the messages it syncs --
populated with the results of
> aa FETCH $UID (X-GM-MSGID X-GM-THRID X-GM-LABELS)
and when syncing the message back to the server, emitting
> aa STORE $UID X-GM-LABELS ($X-GM-LABELS)
with the value taken from the header and these custom headers stripped.
One could then use notmuch to convert from known labels in X-GM-LABELS to
notmuch-internal labels, and have one's MUA edit the X-GM-LABELS header upon
retagging. But then, this already seems overwrought, so I'm not sure how much
value it has.
Given the above, it might be worth considering the notmuch labels as local
conveniences to be used when reading mail most comfortably at my computer,
ignore Gmail's ability to multi-label emails and use the folders to classify
emails for my other devices (eg phones)
Q3: How do you guys' Gmail and notmuch labels interact? How much effort do you
put into making them sync up? What do you do about the duplicate entries?

Finally finally, I'm not sure I 100% understand the guidance re
trashing/expunging and its interaction with Gmail -- do I understand correctly
that the default behaviour is for the Gmail server to automatically delete email
once it's vanished from all labels, preventing batch processing, and that the
recommended behavior instead is to set it to move messages to Trash once their
final copy is expunged?

Thank you,
Gesh

[1]: https://developers.google.com/workspace/gmail/imap/imap-extensions
[2]: https://github.com/gauteh/lieer