Re: [RFC 0/2] add --new-tags= to notmuch-new(1)

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

andreas@rammhold.de venit, vidit, dixit 2021-09-16 14:24:14:
> On 14:03 16.09.21, Michael J Gruber wrote:
> > I very much sympathize with your setup. But I think the real solution
> > would be one of these options:
> > 
> > - use a lock file to prevent your scripts from running concurrently OR
> 
> That would work. I'd love if that could be moved into notmuch such
> that running `notmuch new` will keep a (global) lock until all of the
> messages have been processed and all of the hooks have been executed.
> 
> This is probably tricky to get right consistently across the notmuch
> code base. At least that was one of the comments I recall from a
> conversation on IRC when that topic was brought up.

I don't think it's notmuch's job to do that. But if you call notmuch for
a specific folder you can instead call a wrapper script which keeps a
folder-specific lock until that notmuch returns, and can you pass the
folder to the hooks via environment.

> > - match "tag:new and folder:UNIQUEFOLDER" (or "path:FOO/**")
> >   This should be a perfect substitute for your new-UNIQUE tag.
> 
> How would the files end up in the UNIQUEFOLDER? What I probably forgot
> to mention is that I do not sync only on the Mailbox boundary. I have an
> IAMP IDLE instance for "Inbox" on all of the accounts and then more for
> other folders in those accounts. I could probably script that (wouldn't
> take more than an evening I am sure) but requires a lot more additional
> code.

I assumed that each of your different notmuch calls (from different IDLE
instances) act on different folders or sets of folders, so that you can
distinguish the messages either way.

Depending on your setup, there may still be issues when a second sync
interferes so that the "first" notmuch new tags messages from the
"second" sync. That's exactly what a lock can prevent if you do the sync
in a pre-new hook.

> 
> > As for the implementation you suggest: Basically, you implement
> > overriding the "new.tags" config, and I'm wondering whether it would be
> > worthwhile to implement "notmuch --config-value" instead:
> > 
> > --config-value=SECTION.ITEM=VALUE
> >       Override the config setting for SECTION.ITEM with the VALUE for
> >       this invocation. This takes precedence over any setting in the
> >       config file.
> 
> That is an interesting idea. How would you implement that? Right now it
> looks like all changes in configuration are written to disk when you
> change them. That would require keeping a copy of all the settings in
> RAM (which is probably already the case) and only mutating those without
> writing to disk.

... and notmuch config get called from a hook should return that value,
ideally (I don't know how).

We already have at least these:

notmuch {insert,new,reindex,reply,show} --decrypt overrides index.decrypt
NOTMUCH_DATABASE overrides database.path

and the env vars for config and profile interacting with --config. So I
was hoping for a systematic solution. But I just love "git -c" too much :)

Michael