Add support for specifying tags during "notmuch new"

[David Bremner]

Austin Clements  writes:


> I'm not sure if it's a bad idea or not, but it's materially different
> from the tags in the config.  The tags in the config persist and any
> call to notmuch new from any source (cron, 'G' in Emacs, etc.) will
> pick them up.  Tags specified on the command line don't persist in
> this way.

Well sure, but nothing prevents a motivated user from editing the config
file to have transient settings for the values. I see these patches as
replacing such a hack.

d

Add support for specifying tags during "notmuch new"

[Austin Clements]

Quoth David Bremner on Jul 12 at  4:08 pm:
> Austin Clements  writes:
> 
> > What happens when this script dies in the middle (say, your computer
> > loses power or notmuch tag conflicts with something else on the write
> > lock)?  One advantage of the standard "new" tag approach is that it's
> > easy to write a stateless post-new tagging script that can be killed
> > at any point and restarted.  (You're right that post-new has a
> > concurrency issue, but we should fix that in its own right.)
> 
> Hi David, Hi Austin;
> 
> So, what to do about this patch series? Is it actually a bad idea to
> allow specifying tags for notmuch new? We already allow it via config,
> right, so this just makes things more convenient.

I'm not sure if it's a bad idea or not, but it's materially different
from the tags in the config.  The tags in the config persist and any
call to notmuch new from any source (cron, 'G' in Emacs, etc.) will
pick them up.  Tags specified on the command line don't persist in
this way.

Re: Add support for specifying tags during notmuch new

[David Bremner]

Austin Clements amdra...@mit.edu writes:


 I'm not sure if it's a bad idea or not, but it's materially different
 from the tags in the config.  The tags in the config persist and any
 call to notmuch new from any source (cron, 'G' in Emacs, etc.) will
 pick them up.  Tags specified on the command line don't persist in
 this way.

Well sure, but nothing prevents a motivated user from editing the config
file to have transient settings for the values. I see these patches as
replacing such a hack.

d
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Add support for specifying tags during "notmuch new"

[David Bremner]

Austin Clements  writes:

> What happens when this script dies in the middle (say, your computer
> loses power or notmuch tag conflicts with something else on the write
> lock)?  One advantage of the standard "new" tag approach is that it's
> easy to write a stateless post-new tagging script that can be killed
> at any point and restarted.  (You're right that post-new has a
> concurrency issue, but we should fix that in its own right.)

Hi David, Hi Austin;

So, what to do about this patch series? Is it actually a bad idea to
allow specifying tags for notmuch new? We already allow it via config,
right, so this just makes things more convenient.

d

Re: Add support for specifying tags during notmuch new

[David Bremner]

Austin Clements amdra...@mit.edu writes:

 What happens when this script dies in the middle (say, your computer
 loses power or notmuch tag conflicts with something else on the write
 lock)?  One advantage of the standard new tag approach is that it's
 easy to write a stateless post-new tagging script that can be killed
 at any point and restarted.  (You're right that post-new has a
 concurrency issue, but we should fix that in its own right.)

Hi David, Hi Austin;

So, what to do about this patch series? Is it actually a bad idea to
allow specifying tags for notmuch new? We already allow it via config,
right, so this just makes things more convenient.

d
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: Add support for specifying tags during notmuch new

[Austin Clements]

Quoth David Bremner on Jul 12 at  4:08 pm:
 Austin Clements amdra...@mit.edu writes:
 
  What happens when this script dies in the middle (say, your computer
  loses power or notmuch tag conflicts with something else on the write
  lock)?  One advantage of the standard new tag approach is that it's
  easy to write a stateless post-new tagging script that can be killed
  at any point and restarted.  (You're right that post-new has a
  concurrency issue, but we should fix that in its own right.)
 
 Hi David, Hi Austin;
 
 So, what to do about this patch series? Is it actually a bad idea to
 allow specifying tags for notmuch new? We already allow it via config,
 right, so this just makes things more convenient.

I'm not sure if it's a bad idea or not, but it's materially different
from the tags in the config.  The tags in the config persist and any
call to notmuch new from any source (cron, 'G' in Emacs, etc.) will
pick them up.  Tags specified on the command line don't persist in
this way.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Add support for specifying tags during "notmuch new"

[David Edmondson]

On Fri, May 02 2014, Austin Clements wrote:
>> 2) A periodic mail processing script wants to add new messages to
>>the database, then process those newly added messages to add
>>convenience tags, etc. without worrying about the user or other
>>instances of the script manipulating tags at the same time. Use
>>this approach:
>>  KEY=$RANDOM
>>   notmuch new +$KEY
>>   notmuch tag +notmuch tag:$KEY and to:notmuch at notmuchmail.org
>>   notmuch tag +gnus tag:$KEY and to:ding at gnus.org
>>   ...
>>   notmuch tag -$KEY tag:$KEY
>
> What happens when this script dies in the middle (say, your computer
> loses power or notmuch tag conflicts with something else on the write
> lock)?

It's a problem. I think that I would actually add both 'new' and
'new-$seconds' tags (given that I can't search on wildcarded tags) and
have 'notmuch tag' use only 'new-$seconds'.

The 'new' tag would help recover from failures such as you describe.

> One advantage of the standard "new" tag approach is that it's easy to
> write a stateless post-new tagging script that can be killed at any
> point and restarted.  (You're right that post-new has a concurrency
> issue, but we should fix that in its own right.)
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 310 bytes
Desc: not available
URL: 

[PATCH v2 0/5] Add support for specifying tags during "notmuch new"

[Mark Walters]

Version 2 passes all tests and LGTM. +1

Best wishes

Mark

On Fri, 02 May 2014, David Edmondson  wrote:
> v1:
>
> This patch set allows a user to specify a list of tags to be
> added/removed to messages discovered during "notmuch new".
>
> Two use-cases are envisaged:
> 1) A chunk of messages was just dumped into the configured
>directory by hand, and the user doesn't want the 'inbox' tag
>applied to them. Run 'notmuch new -inbox'.
> 2) A periodic mail processing script wants to add new messages to
>the database, then process those newly added messages to add
>convenience tags, etc. without worrying about the user or other
>instances of the script manipulating tags at the same time. Use
>this approach:
>  KEY=$RANDOM
>notmuch new +$KEY
>notmuch tag +notmuch tag:$KEY and to:notmuch at notmuchmail.org
>notmuch tag +gnus tag:$KEY and to:ding at gnus.org
>...
>notmuch tag -$KEY tag:$KEY
>
> v2: The first version synced tags to flags rather than the other way
> around. Thanks to Mark for complaining at me.
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH v2 0/5] Add support for specifying tags during "notmuch new"

[David Edmondson]

v1:

This patch set allows a user to specify a list of tags to be
added/removed to messages discovered during "notmuch new".

Two use-cases are envisaged:
1) A chunk of messages was just dumped into the configured
   directory by hand, and the user doesn't want the 'inbox' tag
   applied to them. Run 'notmuch new -inbox'.
2) A periodic mail processing script wants to add new messages to
   the database, then process those newly added messages to add
   convenience tags, etc. without worrying about the user or other
   instances of the script manipulating tags at the same time. Use
   this approach:
 KEY=$RANDOM
 notmuch new +$KEY
 notmuch tag +notmuch tag:$KEY and to:notmuch at notmuchmail.org
 notmuch tag +gnus tag:$KEY and to:ding at gnus.org
 ...
 notmuch tag -$KEY tag:$KEY

v2: The first version synced tags to flags rather than the other way
around. Thanks to Mark for complaining at me.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 310 bytes
Desc: not available
URL: 

Add support for specifying tags during "notmuch new"

[Austin Clements]

Quoth David Edmondson on May 02 at  9:15 am:
> This patch set allows a user to specify a list of tags to be
> added/removed to messages discovered during "notmuch new".
> 
> Two use-cases are envisaged:
> 1) A chunk of messages was just dumped into the configured
>directory by hand, and the user doesn't want the 'inbox' tag
>applied to them. Run 'notmuch new -inbox'.
> 2) A periodic mail processing script wants to add new messages to
>the database, then process those newly added messages to add
>convenience tags, etc. without worrying about the user or other
>instances of the script manipulating tags at the same time. Use
>this approach:
>  KEY=$RANDOM
>notmuch new +$KEY
>notmuch tag +notmuch tag:$KEY and to:notmuch at notmuchmail.org
>notmuch tag +gnus tag:$KEY and to:ding at gnus.org
>...
>notmuch tag -$KEY tag:$KEY

What happens when this script dies in the middle (say, your computer
loses power or notmuch tag conflicts with something else on the write
lock)?  One advantage of the standard "new" tag approach is that it's
easy to write a stateless post-new tagging script that can be killed
at any point and restarted.  (You're right that post-new has a
concurrency issue, but we should fix that in its own right.)

Add support for specifying tags during "notmuch new"

[David Edmondson]

This patch set allows a user to specify a list of tags to be
added/removed to messages discovered during "notmuch new".

Two use-cases are envisaged:
1) A chunk of messages was just dumped into the configured
   directory by hand, and the user doesn't want the 'inbox' tag
   applied to them. Run 'notmuch new -inbox'.
2) A periodic mail processing script wants to add new messages to
   the database, then process those newly added messages to add
   convenience tags, etc. without worrying about the user or other
   instances of the script manipulating tags at the same time. Use
   this approach:
 KEY=$RANDOM
 notmuch new +$KEY
 notmuch tag +notmuch tag:$KEY and to:notmuch at notmuchmail.org
 notmuch tag +gnus tag:$KEY and to:ding at gnus.org
 ...
 notmuch tag -$KEY tag:$KEY

Add support for specifying tags during notmuch new

[David Edmondson]

This patch set allows a user to specify a list of tags to be
added/removed to messages discovered during notmuch new.

Two use-cases are envisaged:
1) A chunk of messages was just dumped into the configured
   directory by hand, and the user doesn't want the 'inbox' tag
   applied to them. Run 'notmuch new -inbox'.
2) A periodic mail processing script wants to add new messages to
   the database, then process those newly added messages to add
   convenience tags, etc. without worrying about the user or other
   instances of the script manipulating tags at the same time. Use
   this approach:
 KEY=$RANDOM
 notmuch new +$KEY
 notmuch tag +notmuch tag:$KEY and to:notmuch@notmuchmail.org
 notmuch tag +gnus tag:$KEY and to:d...@gnus.org
 ...
 notmuch tag -$KEY tag:$KEY

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH v2 0/5] Add support for specifying tags during notmuch new

[David Edmondson]

v1:

This patch set allows a user to specify a list of tags to be
added/removed to messages discovered during notmuch new.

Two use-cases are envisaged:
1) A chunk of messages was just dumped into the configured
   directory by hand, and the user doesn't want the 'inbox' tag
   applied to them. Run 'notmuch new -inbox'.
2) A periodic mail processing script wants to add new messages to
   the database, then process those newly added messages to add
   convenience tags, etc. without worrying about the user or other
   instances of the script manipulating tags at the same time. Use
   this approach:
 KEY=$RANDOM
 notmuch new +$KEY
 notmuch tag +notmuch tag:$KEY and to:notmuch@notmuchmail.org
 notmuch tag +gnus tag:$KEY and to:d...@gnus.org
 ...
 notmuch tag -$KEY tag:$KEY

v2: The first version synced tags to flags rather than the other way
around. Thanks to Mark for complaining at me.


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH v2 0/5] Add support for specifying tags during notmuch new

[Mark Walters]

Version 2 passes all tests and LGTM. +1

Best wishes

Mark

On Fri, 02 May 2014, David Edmondson d...@dme.org wrote:
 v1:

 This patch set allows a user to specify a list of tags to be
 added/removed to messages discovered during notmuch new.

 Two use-cases are envisaged:
 1) A chunk of messages was just dumped into the configured
directory by hand, and the user doesn't want the 'inbox' tag
applied to them. Run 'notmuch new -inbox'.
 2) A periodic mail processing script wants to add new messages to
the database, then process those newly added messages to add
convenience tags, etc. without worrying about the user or other
instances of the script manipulating tags at the same time. Use
this approach:
  KEY=$RANDOM
notmuch new +$KEY
notmuch tag +notmuch tag:$KEY and to:notmuch@notmuchmail.org
notmuch tag +gnus tag:$KEY and to:d...@gnus.org
...
notmuch tag -$KEY tag:$KEY

 v2: The first version synced tags to flags rather than the other way
 around. Thanks to Mark for complaining at me.
 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: Add support for specifying tags during notmuch new

[Austin Clements]

Quoth David Edmondson on May 02 at  9:15 am:
 This patch set allows a user to specify a list of tags to be
 added/removed to messages discovered during notmuch new.
 
 Two use-cases are envisaged:
 1) A chunk of messages was just dumped into the configured
directory by hand, and the user doesn't want the 'inbox' tag
applied to them. Run 'notmuch new -inbox'.
 2) A periodic mail processing script wants to add new messages to
the database, then process those newly added messages to add
convenience tags, etc. without worrying about the user or other
instances of the script manipulating tags at the same time. Use
this approach:
  KEY=$RANDOM
notmuch new +$KEY
notmuch tag +notmuch tag:$KEY and to:notmuch@notmuchmail.org
notmuch tag +gnus tag:$KEY and to:d...@gnus.org
...
notmuch tag -$KEY tag:$KEY

What happens when this script dies in the middle (say, your computer
loses power or notmuch tag conflicts with something else on the write
lock)?  One advantage of the standard new tag approach is that it's
easy to write a stateless post-new tagging script that can be killed
at any point and restarted.  (You're right that post-new has a
concurrency issue, but we should fix that in its own right.)
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch