andr...@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
>
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
andr...@rammhold.de venit, vidit, dixit 2021-09-16 12:25:15:
> I've recently became a little annoyed with a race condition in my current
> notmuch setup that originates from only having a single set of new tags for
> all notmuch-new(1) invocations. In the past I've mentioned this a couple of
>
From: Andreas Rammhold
This introduces a new argument to notmuch-new(1) that allows specfying
the tags that should be applied to new messages. The new option takes
precedence over the new.tags setting configured in the configuration
file.
The need for this option did arise while due to
From: Andreas Rammhold
This factors out the code required to initialize a
notmuch_config_values_t from a string into a dedicated function. By
exposing this function we can allow consumers (such as notmuch-new(1))
to customize certain configuration values via command line flags.
---
I've recently became a little annoyed with a race condition in my current
notmuch setup that originates from only having a single set of new tags for
all notmuch-new(1) invocations. In the past I've mentioned this a couple of
times in the IRC channel and now I got around to implement a basic
