[PATCH] emacs: call "notmuch tag" only once when archiving a thread

[Mark Walters]

> There's been quite a bit of discussion on fixing this properly.  See,
> for example
> id:"CAH-f9WsPj=1Eu=g3sOePJgCTBFs6HrLdLq18xMEnJ8aZ00yCEg at mail.gmail.com".
> The gist is that we need to include message IDs (or document IDs) in
> the search output and use these in tagging operations, rather than the
> unstable thread:XXX queries.  Unfortunately, actually fixing this got
> stalled since adding this information the text format is a fool's
> errand (having been the fool, I can say this!), so we need to switch
> Emacs over to using the JSON search format first.  However, once
> that's done, it's a relatively simple change.

I will just mention a different possible solution to this problem. I
think it is probably more hassle than its worth but just in case someone
sees how to do it nicely. 

The idea is to try and put the race-free solution into the command-line
notmuch rather than the emacs part.

I will just consider one race to start with: the race in notmuch
search/notmuch tag. notmuch search gives us just the thread-ids and what
is in that thread can change. So we could ask for a "cookie" (some short
unique identifier) and notmuch itself would store the state of its
output (i.e., the thread-ids together with the message-ids and the
matched message-ids).

Then notmuch tag could be called with this cookie to say "apply this tag
to the threads as they were at cookie.

example use
notmuch search --cookie <query>
prints a cookie followed by the output of the search

notmuch tag --cookie=cookievalue +sometag matched-thread:id .. \
                                 all-thread:id .. <other search terms>

and notmuch would replace the matched-thread:id by the (matching)
message-ids in thread it stored at time cookievalue and all-thread by
all the messages at time cookievalue.

The nice feature is that this makes it easy for all clients to be race
free (not just emacs). The backend has the information to hand: there is
no encoding and decoding (via text or JSON) so storing message-ids etc
is simpler.  It also means that if notmuch wants to use document-ids
internally it can: it does not become a public interface.

The downside is trying to do the argument parsing in c and we have do
some reference counting or something to delete the cookies state at some
point.

Anyway it's just a thought.

Best wishes

Mark