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

[andreas@rammhold.de]

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.

> - 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.


> 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.


> I know this raises the question which config any hooks will see, but
> that is the same for your implementation.

Yeah, I was thinking about that as well. I did check if notmuch actually
passed anything via environment vars to the hooks. That doesn't seem to
be the case.

> You can override the complete config by specifying a different file
> already, of course, so you could script that.

Yes, that is also something I considered but I'd rather avoid that. I've
had some issues with defining the notmuch configuration in the past. For
some reason it always failed to find the file or load the correct one :(
Was probably some local issue - I hope.