Race condition for '*' command

2011-06-25 Thread Robin Green
Hi,

A race condition in the '*' command was noted when it was first
proposed. It looks to me like it still exists - has anything been done
about it?

Right now what I am doing is killing fetchmail, then using the '*'
command, then starting fetchmail again in daemon mode, which is a little
inconvenient. You see, in my setup fetchmail calls procmail to deliver
mails, and procmail calls "notmuch new" after delivering every mail.

Thanks,
Robin Green


Re: Race condition for '*' command

2011-06-25 Thread Jameson Graef Rollins
On Sat, 25 Jun 2011 23:18:52 +0100, Robin Green  wrote:
> A race condition in the '*' command was noted when it was first
> proposed. It looks to me like it still exists - has anything been done
> about it?

Hi, Robin.  Can you explain what you mean by the "'*' command"?  Are you
referring to '*' as a search term?  It's not a command, but it's the
only place I know of where notmuch uses the '*' character.  Can you
explain in a little more detail what exactly your issue is?

jamie.


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


Race condition for '*' command

2011-06-25 Thread Jameson Graef Rollins
On Sat, 25 Jun 2011 23:18:52 +0100, Robin Green  wrote:
> A race condition in the '*' command was noted when it was first
> proposed. It looks to me like it still exists - has anything been done
> about it?

Hi, Robin.  Can you explain what you mean by the "'*' command"?  Are you
referring to '*' as a search term?  It's not a command, but it's the
only place I know of where notmuch uses the '*' character.  Can you
explain in a little more detail what exactly your issue is?

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110625/bc338cad/attachment.pgp>


Race condition for '*' command

2011-06-25 Thread Robin Green
Hi,

A race condition in the '*' command was noted when it was first
proposed. It looks to me like it still exists - has anything been done
about it?

Right now what I am doing is killing fetchmail, then using the '*'
command, then starting fetchmail again in daemon mode, which is a little
inconvenient. You see, in my setup fetchmail calls procmail to deliver
mails, and procmail calls "notmuch new" after delivering every mail.

Thanks,
Robin Green
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Notmuch scripts

2011-06-25 Thread c...@te2000.cz
similar experience
> with my computer that I get from books. (Though I'm still waiting for
> much better contrast from my computer displays?e-ink definitely helps a
> lot for the very static use cases).

You'd definitely wouldn't like my cyan for unseen messages then. :-)
That's why I'd like to get that in globally configurable, see above on
notmuch-pager

> >   * New message processing. Currently I check for spam and I mute
> > selected threads. I can see this can be made quite configurable.
> > Maybe create procmail equivalent for notmuch? :-)
> 
> I think lots of us have various hand-written scripts that call out to
> "notmuch tag" a bunch. It's definitely a common idiom to have "notmuch
> new" add a new tag, have the new-mail-processing script operate on
> tag:new, and then have that script remove tag:new from the things it
> processed.

I actually don't do much tagging, as saved searches seem more flexible
to me. The current implementation does three things (apart from having
nice progress meter):
  * applies 'sent' tag to emails from addresses in your config file.
This can be accomplished by saved searches too, bot it was more
convenient to me to implement it here.
  * runs spam check on the mail
  * makes 'mute' tag span whole threads

The last thing is not that easy to do in pure shell script.

I'm not sure if some domain-specific language would be that big
improvement over status quo, that it would be worth implementing.
It would be first necessary to asses which features are useful and what
people need. Apart from what it currently does I do think that it would
be useful if it could move messages around .

> An alternative approach has been proposed to make "notmuch new" able to
> act on specified messages, (and accept an explicit list of tags to
> add). That would make it much easier to actually use existing tools like
> procmail directly with notmuch. Some people are currently using the
> notmuch-deliver.sh script in use cases like this. (And that script is
> another existing candidate for contrib.)

I am actually considering using something like that together with
dovecot on my server, I want to get some experience with using notmuch
first.

Thanks for your elaborate response. :-)
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110625/6454c6da/attachment-0001.pgp>


[PATCH] libnotmuch: fix typos in CLEAN setting, add file

2011-06-25 Thread da...@tethera.net
From: David Bremner 

- c0961e6 introduced a missing slash between $(dir)$(LIBNAME) and missing
  $(dir) in front of libnotmuch.a
- cdf1c70a created a file $(dir)/notmuch.h.gch and neglected to
  add it to CLEAN
---

Here is an updated version. I'm not sure the best way to do a test of
the cleaning; maybe we should ship a MANIFEST file containing the
output of git ls-files. I'm not sure how much churn this would cause
in git.  Perhaps it could be treated like version, and generated from
git if possible. In any case I guess this couldn't really be part of
our regular test suite, because all the other tests would fail ;).

 lib/Makefile.local |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/lib/Makefile.local b/lib/Makefile.local
index a33ba34..eaa8af4 100644
--- a/lib/Makefile.local
+++ b/lib/Makefile.local
@@ -103,4 +103,6 @@ install-$(dir): $(dir)/$(LIBNAME)
$(LIBRARY_INSTALL_POST_COMMAND)

 SRCS  := $(SRCS) $(libnotmuch_c_srcs) $(libnotmuch_cxx_srcs)
-CLEAN := $(CLEAN) $(libnotmuch_modules) $(dir)/$(SONAME) $(dir)/$(LINKER_NAME) 
$(dir)$(LIBNAME) libnotmuch.a notmuch.aux notmuch.sym
+CLEAN += $(libnotmuch_modules) $(dir)/$(SONAME) $(dir)/$(LINKER_NAME)
+CLEAN += $(dir)/$(LIBNAME) $(dir)/libnotmuch.a notmuch.aux notmuch.sym
+CLEAN += $(dir)/notmuch.h.gch
-- 
1.7.5.3



[PATCH] libnotmuch: fix typos in CLEAN setting, add file

2011-06-25 Thread david
From: David Bremner 

- c0961e6 introduced a missing slash between $(dir)$(LIBNAME) and missing
  $(dir) in front of libnotmuch.a
- cdf1c70a created a file $(dir)/notmuch.h.gch and neglected to
  add it to CLEAN
---

Here is an updated version. I'm not sure the best way to do a test of
the cleaning; maybe we should ship a MANIFEST file containing the
output of git ls-files. I'm not sure how much churn this would cause
in git.  Perhaps it could be treated like version, and generated from
git if possible. In any case I guess this couldn't really be part of
our regular test suite, because all the other tests would fail ;).

 lib/Makefile.local |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/lib/Makefile.local b/lib/Makefile.local
index a33ba34..eaa8af4 100644
--- a/lib/Makefile.local
+++ b/lib/Makefile.local
@@ -103,4 +103,6 @@ install-$(dir): $(dir)/$(LIBNAME)
$(LIBRARY_INSTALL_POST_COMMAND)
 
 SRCS  := $(SRCS) $(libnotmuch_c_srcs) $(libnotmuch_cxx_srcs)
-CLEAN := $(CLEAN) $(libnotmuch_modules) $(dir)/$(SONAME) $(dir)/$(LINKER_NAME) 
$(dir)$(LIBNAME) libnotmuch.a notmuch.aux notmuch.sym
+CLEAN += $(libnotmuch_modules) $(dir)/$(SONAME) $(dir)/$(LINKER_NAME)
+CLEAN += $(dir)/$(LIBNAME) $(dir)/libnotmuch.a notmuch.aux notmuch.sym
+CLEAN += $(dir)/notmuch.h.gch
-- 
1.7.5.3

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