[RFC][PATCH] tags_to_maildir_flags: Add option to not move messages from "new/" to "cur/"

[Louis Rilling]

On 24/06/11 11:19 -0400, Austin Clements wrote:
> Welcome to notmuch!

Thanks!

> 
> From your description, I assume you're using both notmuch and another
> MUA simultaneously.  I'm betting that MUA is mutt (though please
> correct me if I'm wrong).

Correct :)

> 
> Unfortunately, mutt's interpretation of maildir doesn't agree with the
> rest of the world.  I don't know of any other MUA that exposes the
> distinction between mail in the "new" directory and mail in the "old"
> directory (at least Dovecot, Evolution, Gnus, Kmail, and of course
> notmuch don't).  In other MUA's, any mail in the "new" directory is
> immediately moved to "cur" and "new" mail is simply anything without
> the seen flag.  mutt, on the other hand, only considers mail in the
> "new" directory to be "new".
> 
> While the maildir specification is a little vague, it strongly implies
> two things that mutt's approach violates: mail should never move from
> "cur" to "new", and only mail in "cur" can have flags [1].  While it
> never states it outright, the philosophy is that "new" is simply a
> staging ground for incoming mail, not a user-visible state (and
> certainly not user-manipulable).

Thanks for the detailed explanation.

> 
> Because of this, I don't think notmuch is the right place to change
> this (certainly not in a way that would also violate the spec).  Could
> you elaborate a bit on your workflow?  (In particular, are you using
> mutt's distinction between new and old?)  Maybe we can find an
> alternate solution.

Yes my quick "mood-dependent" filtering just acts on new (as shown by mutt)
mails, while old mails are kept until either 1) they can be read (yes, this
happens!), or 2) they can be archived (because they might be interesting in
some future), or 3) they can be deleted (eg. became too old to be worth
reading them).

However, I don't think that I need the violating behavior of mutt: new mails
are just new, not replied to/read, or anything else. The only rare cases in
which I may set back the new flag are when I mistakenly start reading an email
(wrong keystroke most of the time). Even in that case, I don't care if the mail
becomes old (ie moves to cur/).

Maybe the alternate solution could consist in simply not renaming emails having
no flags to be changed (Currently notmuch_message_tags_to_maildir_flags()
unconditionally moves messages from new/ to cur/). This would even lead to a
shorter patch :) Do you think that this would be acceptable?

Thanks,

Louis

> 
> [1] There's a bug open about the second problem (thanks to ccxCZ for
> finding this):
> http://dev.mutt.org/trac/ticket/2476
> Of course, fixing that implies addressing the first problem, too.
> 
> On Thu, Jun 23, 2011 at 11:36 AM, Louis Rilling  wrote:
> > notmuch_message_tags_to_maildir_flags() moves messages from maildir 
> > directory
> > "new/" to maildir directory "cur/", which makes messages lose their "new" 
> > status
> > in the MUA. However some users want to keep this "new" status after, for
> > instance, an auto-tagging of new messages.
> >
> > This patch introduces notmuch_message_tags_to_maildir_flags_preserve(), 
> > which
> > does the same job as notmuch_message_tags_to_maildir_flags() except moving
> > from "maildir "new/" to maildir "cur/". A new option "preserve_new" is
> > introduced in "[maildir]" section of .notmuch-config, so that users can
> > configure whether commands "notmuch tag" and "notmuch restore" preserve the
> > "new" status or not.
> >
> > Signed-off-by: Louis Rilling 
> > ---
> > Hi,
> >
> > I'm in the process of using notmuch, but the issue "addressed" by this patch
> > would make me change my habits a bit too fast. I use the "new" status for
> > quickly checking (often without reading) which emails I just received,
> > implementing some kind of context/mood/daytime-dependent quick filtering. 
> > I'd
> > also like to run a pre-tagging script automatically when synchronizing
> > periodically (and automatically too) my mailboxes. But the current behavior 
> > of
> > "notmuch tag" makes me lose my quick filtering ability.
> >
> > This patch is mostly written for discussion. It is certainly not polished 
> > (API,
> > ABI, bindings) and not tested at all. In particular, I know that there are 
> > some
> > plans to customize flags synchronization, but I don't know how the library 
> > API
> > could/should be impacted.
> >
> > Thanks for your comments!
> >
> > Louis

[PATCH] fix sum moar typos

[Pieter Praet]

On Thu, 23 Jun 2011 16:22:27 -0700, Carl Worth  wrote:
Non-text part: multipart/signed
> On Mon, 20 Jun 2011 22:14:21 +0200, Pieter Praet  wrote:
> > Various typo fixes in docs, docstrings, comments, etc...
> > 
> > Signed-off-by: Pieter Praet 
> 
> Thanks for these fixes, Pieter!

My pleasure.

> I've pushed these all out now. I split the original commit up into 6
> commits that each touch different kinds of text, (non-code text files,
> comments within source files, error messages within source files, etc.)
> 
> The idea there is that these different kinds of text have different
> potential impacts on the correctness of the code. So some release
> manager might be willing to include one kind of change, but not another,
> for example.

Agreed.

> Also, it made things a bit easier to read. There were two incorrect typo
> fixes in the original commit which I fixed:
> 
> > -"\tSeveral notmuch commands accept a comman syntax for search\n"
> > +"\tSeveral notmuch commands accept a command syntax for search\n"
> 
> This is now "common syntax".
> 
> > -# Remember stdout and stderr file descriptios and redirect test
> > +# Remember stdout and stderr file descriptions and redirect test
> 
> This is now "file descriptors".
> 
> And one change where I left the original text unchanged:
> 
> >   * A non-NULL return value is guaranteed to be a valid string pointer
> >   * pointing to the characters "new/" or "cur/", (but not
> > - * NUL-terminated).
> > + * NULL-terminated).
> 
> This comment uses "NULL" to describe a NULL pointer and "NUL" to
> describe the ASCII character '\0'. (I know that "NUL" is a really
> annoying historically misspelled abbreviation, but it is in standard
> usage I believe---see ASCII(7) for example.)

Prime examples of "or even made some new ones" [1] :D

> Meanwhile, I was almost tempted to leave this misspelling unchanged:
> 
> > -(error "%s is a file. Can't creat maildir." path))
> > +(error "%s is a file. Can't create maildir." path))
> 
> Since that's also a classic historically misspelled abbreviation. ;-)
> 
> Oh, and let me just thank you for being so thorough! There were several
> fixes you made that could obviously not be caught by an automated spell
> checker:
> 
> > ---part=id", (David Edmonson wants to rewrite some of "notmuch show" to
> > +--part=id", (David Edmondson wants to rewrite some of "notmuch show" to
> ...
> >  (defun notmuch-user-other-email ()
> > -  "Return the user.primary_email value (as a list) from the notmuch 
> > configuration."
> > +  "Return the user.other_email value (as a list) from the notmuch 
> > configuration."
> ...
> >  (defcustom notmuch-after-tag-hook nil
> > -  "Hooks that are run before tags of a message are modified.
> > +  "Hooks that are run after tags of a message are modified.
> ...
> > -The debian packaging exists in the top-level "debian" directory within
> > +The Debian packaging exists in the top-level "debian" directory within
> 
> Those all demonstrate a particular eye for detail?well done! For a
> couple of those, I almost gave them their own commits.
> 
> In passing, let me point out the most amusing typo I saw in the patch:
> 
> > -} /* Appleasing Emacs */
> > +} /* Appeasing Emacs */
> 
> I almost hate to see that go, because I like the pleasing portmanteau
> sound of "appleasing". Please applease me and leave this pleasing typo?
> 
> Admittedly, that's not in code that's originally mine, so I can't say it
> wasn't intentional either.
> 
> Finally, *many* of the typos and misspellings were originally mine. It's
> certainly embarrassing to see so many (and so many repeats). It was also
> embarrassing to see how many misspellings I committed while typing the
> commit messages, (fortunately I rebased many away).

Let's turn that around:

Comments and commit messages are (understandably) a mere afterthought
for most coders, including myself, and are thus often very terse or
even nonexistent, which automatically translates to less typos (y=kx).

You however, seem to be incredibly disciplined in this respect,
so statistically speaking, you're destined to become typo-king,
and you have every reason to be *proud* of it. :D

The only thing you could possibly have to be embarrassed about,
is insufficient laziness (which, for programmers, is considered a
virtue) ;)

> And now I'm starting to get paranoid about this message. Am I really
> brave enough to type words like "embarrassing", "misspelling", and
> "committed" here?
> 
> Thanks again,
> 
> -Carl
Non-text part: application/pgp-signature


Peace

-- 
Pieter


[1] id:"1307202852-4398-1-git-send-email-pieter at praet.org"

[PATCH 2/2] search --output=files: Output all filenames for each matching message

[Mark Anderson]

Messages in the database can have multiple files associated with a
single message-id, but until now only one filename for each message
has been reported by "notmuch search --output=files"

Signed-off-by: Mark Anderson 
---

Perhaps someone can offer a little help making the "separator" code
tighter, but this works.

 notmuch-search.c |   29 ++---
 1 files changed, 22 insertions(+), 7 deletions(-)

diff --git a/notmuch-search.c b/notmuch-search.c
index 616fe68..faccaf7 100644
--- a/notmuch-search.c
+++ b/notmuch-search.c
@@ -275,6 +275,7 @@ do_search_messages (const search_format_t *format,
 {
 notmuch_message_t *message;
 notmuch_messages_t *messages;
+notmuch_filenames_t *filenames;
 int first_message = 1;

 messages = notmuch_query_search_messages (query);
@@ -289,19 +290,33 @@ do_search_messages (const search_format_t *format,
 {
message = notmuch_messages_get (messages);

-   if (! first_message)
-   fputs (format->item_sep, stdout);
-
if (output == OUTPUT_FILES) {
-   format->item_id (message, "",
-notmuch_message_get_filename (message));
+   filenames = notmuch_message_get_filenames (message);
+
+   for (;
+notmuch_filenames_valid (filenames);
+notmuch_filenames_move_to_next (filenames))
+   {
+   if (! first_message)
+   fputs (format->item_sep, stdout);
+
+   format->item_id (message, "",
+notmuch_filenames_get (filenames));
+
+   first_message = 0;
+   }
+   
+   notmuch_filenames_destroy( filenames );
+
} else { /* output == OUTPUT_MESSAGES */
+   if (! first_message)
+   fputs (format->item_sep, stdout);
+
format->item_id (message, "id:",
 notmuch_message_get_message_id (message));
+   first_message = 0;
}

-   first_message = 0;
-
notmuch_message_destroy (message);
 }

-- 
1.7.4.1

[PATCH 1/2] test:Expect multiple filenames for message with multiple files

[Mark Anderson]

Update the test mail corpus to have two files with the same content to
expose the bug where a single message with multiple filenames only
reports a single filename.

Update expected results for search --output=files to match new
behavior for multiple files corresponding to a single message

Signed-off-by: Mark Anderson 
---

I just picked the smallest message and copied it to a new name.  This
 could certainly be done to a much larger degree.

 test/corpus/cur/51:2, |   12 
 test/search-output|2 ++
 2 files changed, 14 insertions(+), 0 deletions(-)
 create mode 100644 test/corpus/cur/51:2,

diff --git a/test/corpus/cur/51:2, b/test/corpus/cur/51:2,
new file mode 100644
index 000..f522f69
--- /dev/null
+++ b/test/corpus/cur/51:2,
@@ -0,0 +1,12 @@
+From: "Aron Griffis" 
+To: notmuch at notmuchmail.org
+Date: Tue, 17 Nov 2009 18:21:38 -0500
+Subject: [notmuch] archive
+Message-ID: <20091117232137.GA7669 at griffis1.net>
+
+Just subscribed, I'd like to catch up on the previous postings,
+but the archive link seems to be bogus?
+
+Thanks,
+Aron
+
diff --git a/test/search-output b/test/search-output
index 3c875cd..10291c3 100755
--- a/test/search-output
+++ b/test/search-output
@@ -207,6 +207,7 @@ MAIL_DIR/cur/22:2,
 MAIL_DIR/cur/21:2,
 MAIL_DIR/cur/19:2,
 MAIL_DIR/cur/18:2,
+MAIL_DIR/cur/51:2,
 MAIL_DIR/cur/20:2,
 MAIL_DIR/cur/17:2,
 MAIL_DIR/cur/16:2,
@@ -263,6 +264,7 @@ cat 

Debian package not building

[Jameson Graef Rollins]

Hey, folks.  As of today I am for some reason no longer able to build
the Notmuch Debian package.  I'm using the same build technique I have
been using for a while (git-buildpackage).  The tail of the failing
build log is pasted at the bottom of this message.  Is anyone else
encountering anything like this?

I don't see what of the recent packaging changes, other than the RPATH
stuff, could be affecting this, and I get the same failure even if I
revert the revert of the RPATH override (ie. RPATH_LDFLAGS auto-build
override in place).  I did recently do a system upgrade, so it's
possible that something there could have caused the problem.

What could be preventing dpkg-shlibdeps from finding libpthread.so.0 or
libc.so.6?

jamie.


servo:~/src/notmuch/git [master] 1$ git buildpackage -us -uc --git-ignore-branch
...
dpkg-shlibdeps: error: couldn't find library libpthread.so.0 needed by 
debian/notmuch/usr/bin/notmuch (ELF format: 'elf64-x86-64'; RPATH: '').
dpkg-shlibdeps: error: couldn't find library libc.so.6 needed by 
debian/notmuch/usr/bin/notmuch (ELF format: 'elf64-x86-64'; RPATH: '').
dpkg-shlibdeps: error: Cannot continue due to the errors listed above.
Note: libraries are not searched in other binary packages that do not have any 
shlibs or symbols file.
To help dpkg-shlibdeps find private libraries, you might need to set 
LD_LIBRARY_PATH.
dh_shlibdeps: dpkg-shlibdeps -Tdebian/notmuch.substvars 
debian/notmuch/usr/bin/notmuch returned exit code 2
make: *** [binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2
debuild: fatal error at line 1340:
dpkg-buildpackage -rfakeroot -D -us -uc -i -I failed
gbp:error: debuild -i -I returned 29
gbp:error: Couldn't run 'debuild -i -I -us -uc'
servo:~/src/notmuch/git [master] 1$ 
-- 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/20110624/8ca4b80a/attachment-0001.pgp>

Notmuch scripts

[c...@te2000.cz]

Hello list!

As some of you know I have written several scripts that aid using
notmuch, including an alternative to the notmuch-mutt perl script.

Since Carl Worth consented to include them into official distribution
I am now cleaning them up, writing docs and extending it so it covers
all features notmuch-mutt currently has.

They can currently be obtained by:
bzr branch http://webprojekty.cz/ccx/bzr/zmuch
Or you can browse the code at:
http://webprojekty.cz/ccx/loggerhead/zmuch/files

During the process of polishing the scripts I thought about few things
that may be interesting to other people integrating notmuch, so let me
hear your opinions. :-)

$NOTMUCH and proxies:
There are applications (whether full-blown interfaces or simple scripts)
that use notmuch. There are scrips that work as proxies to actual
notmuch, eg. by invoking ssh to a machine where the mails are, or
processing the argument list and expanding saved searches. Therefore it
would be very practical if the path to actual executable would be
configurable. Thus I propose:

  * Every application that does not act as a proxy should use
environment variable NOTMUCH to find the actual notmuch executable.
If not defined or empty, just execute 'notmuch' as usual.

  * Every application that acts as a proxy should ignore the NOTMUCH
variable, instead it should be configurable in other way
(configuration file or something easily changeable). This way
chaining of proxies will be possible.

Configuration and temporary files:
I like XDG specification. I think it's bit unnecessary to have to have
config files that belong only to few scripts littered all around my
homedir. Also I think it's reasonable that user would be able to specify
where to put the temporary files. That said atm I have ~/.zmuch as the
only config file, as it felt bit weird to create new directory for just
one file. But as I'm preparing the scripts I see more and more things
that are specific to my setup and I would like them to be configurable.
These are:

  * Spam filter. Do you guys use any? What does it's interface look like?
I currently use bsfilter which I've found does it's job pretty well.

  * Colors. I use bright fg on dark bg, but I understand somebody won't
be happy with this choice.

  * 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? :-)

Thanks for notmuch! I look forward to your responses.
Jan Pobrislo (ccxCZ at freenode)
-- 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/20110624/a034f0ad/attachment.pgp>

Notmuch scripts

[Carl Worth]

cation.

I'm missing some context to know what you're suggesting here.

> I think it's bit unnecessary to have to have
> config files that belong only to few scripts littered all around my
> homedir.

We should be able to put configuration for contrib tools into the main
notmuch configuration file. If your tools don't want to read that file
directly, they should be able to get by with the interfaces provided by
"notmuch config set" and "notmuch config get". Obviously, each tool
should create its own section in the configuration file.

Is that an insane plan?

>   * Spam filter. Do you guys use any? What does it's interface look like?
> I currently use bsfilter which I've found does it's job pretty
> well.

I've currently got amavis and spamassassin adding extra headers, (and
below a certain threshold I've got maildrop delivering detected spam to
a separate maildir).

Currently, notmuch never sees the detected spam. Ever since we got
folder: support I've been meaning to let notmuch see it so that I can
use notmuch to dig into my spam when I suspect something got
mis-detected.

I don't currently have any system for getting user-provided feedback
into my spam filtering. Do you get that with bsfilter?

>   * Colors. I use bright fg on dark bg, but I understand somebody won't
> be happy with this choice.

I'm pretty-much black-on-white only. I really want a 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).

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

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

-Carl

-- 
carl.d.worth at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110624/2ae6ce5c/attachment.pgp>

[RFC][PATCH] tags_to_maildir_flags: Add option to not move messages from "new/" to "cur/"

[Austin Clements]

Welcome to notmuch!

>From your description, I assume you're using both notmuch and another
MUA simultaneously.  I'm betting that MUA is mutt (though please
correct me if I'm wrong).

Unfortunately, mutt's interpretation of maildir doesn't agree with the
rest of the world.  I don't know of any other MUA that exposes the
distinction between mail in the "new" directory and mail in the "old"
directory (at least Dovecot, Evolution, Gnus, Kmail, and of course
notmuch don't).  In other MUA's, any mail in the "new" directory is
immediately moved to "cur" and "new" mail is simply anything without
the seen flag.  mutt, on the other hand, only considers mail in the
"new" directory to be "new".

While the maildir specification is a little vague, it strongly implies
two things that mutt's approach violates: mail should never move from
"cur" to "new", and only mail in "cur" can have flags [1].  While it
never states it outright, the philosophy is that "new" is simply a
staging ground for incoming mail, not a user-visible state (and
certainly not user-manipulable).

Because of this, I don't think notmuch is the right place to change
this (certainly not in a way that would also violate the spec).  Could
you elaborate a bit on your workflow?  (In particular, are you using
mutt's distinction between new and old?)  Maybe we can find an
alternate solution.

[1] There's a bug open about the second problem (thanks to ccxCZ for
finding this):
http://dev.mutt.org/trac/ticket/2476
Of course, fixing that implies addressing the first problem, too.

On Thu, Jun 23, 2011 at 11:36 AM, Louis Rilling  wrote:
> notmuch_message_tags_to_maildir_flags() moves messages from maildir directory
> "new/" to maildir directory "cur/", which makes messages lose their "new" 
> status
> in the MUA. However some users want to keep this "new" status after, for
> instance, an auto-tagging of new messages.
>
> This patch introduces notmuch_message_tags_to_maildir_flags_preserve(), which
> does the same job as notmuch_message_tags_to_maildir_flags() except moving
> from "maildir "new/" to maildir "cur/". A new option "preserve_new" is
> introduced in "[maildir]" section of .notmuch-config, so that users can
> configure whether commands "notmuch tag" and "notmuch restore" preserve the
> "new" status or not.
>
> Signed-off-by: Louis Rilling 
> ---
> Hi,
>
> I'm in the process of using notmuch, but the issue "addressed" by this patch
> would make me change my habits a bit too fast. I use the "new" status for
> quickly checking (often without reading) which emails I just received,
> implementing some kind of context/mood/daytime-dependent quick filtering. I'd
> also like to run a pre-tagging script automatically when synchronizing
> periodically (and automatically too) my mailboxes. But the current behavior of
> "notmuch tag" makes me lose my quick filtering ability.
>
> This patch is mostly written for discussion. It is certainly not polished 
> (API,
> ABI, bindings) and not tested at all. In particular, I know that there are 
> some
> plans to customize flags synchronization, but I don't know how the library API
> could/should be impacted.
>
> Thanks for your comments!
>
> Louis

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

[Carl Worth]

On Fri, 24 Jun 2011 07:53:44 -0300, david at tethera.net wrote:
> From: David Bremner 

Hi David,

Thanks for the fix. A couple of nit-picky comments on the commit itself
first:

> - c0961e6 introduced a missing slash and
> - cdf1c70a created a file and neglected to add it to clean

I'd put a little more detail in the commit message here:

- c0961e6 introduced a missing slash $(dir)$(LIBNAME)
- cdf1c70a created $(dir)/notmuch.h.gch and neglected to add it to clean

> The former seems to have been harmless, so maybe someone (Carl?) can
> check if $(dir)/$(LIBNAME) really needs to be removed?

This auxiliary text should be below the "---" line in the email so that
it won't be in the commit message after I do "git am". (As is, I'd have
to do extra work to "git commit --amend" this text away).

As for the actual question, yes, $(dir)/$(LIBNAME) is supposed to be
cleaned and is not getting cleaned. I've got libnotmuch.so.1.{1,2,3,4}.0
all sitting around never cleaned.

> -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) libnotmuch.a notmuch.aux notmuch.sym 

Meanwhile, I notice now that "libnotmuch.a" is also wrong, (should be
"$(dir)/libnotmuch.a).

Clearly we could use some testing of our "make clean" target to ensure
it actually works. Does the Debian stuff not test anything like this?
(Maybe I'm thinking of typical testing done by autoconf/automake's "make
distcheck" that we haven't replicated yet.)

-Carl

-- 
carl.d.worth at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110624/3636d507/attachment.pgp>

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

[da...@tethera.net]

From: David Bremner 

- c0961e6 introduced a missing slash and
- cdf1c70a created a file and neglected to add it to clean

The former seems to have been harmless, so maybe someone (Carl?) can
check if $(dir)/$(LIBNAME) really needs to be removed?
---
 lib/Makefile.local |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/lib/Makefile.local b/lib/Makefile.local
index a33ba34..acf257a 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) libnotmuch.a notmuch.aux notmuch.sym 
+CLEAN += $(dir)/notmuch.h.gch
-- 
1.7.5.3

[PATCH] test: remove useless test_emacs call from an emacs FCC test

[Dmitry Kurochkin]

---
 test/emacs |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/test/emacs b/test/emacs
index 9b5d485..6f82b08 100755
--- a/test/emacs
+++ b/test/emacs
@@ -124,7 +124,6 @@ mkdir -p mail/sent-string/new
 mkdir -p mail/sent-string/tmp

 test_begin_subtest "notmuch-fcc-dirs set to a string"
-test_emacs "(setq notmuch-fcc-dirs nil) (notmuch-mua-mail) (princ 
(buffer-string))" > OUTPUT
 test_emacs "(setq notmuch-fcc-dirs \"sent-string\") (notmuch-mua-mail) (princ 
(buffer-string))" > OUTPUT
 cat 

[PATCH 14/25] Fix old style notmuch-fcc-dirs configuration check.

[Dmitry Kurochkin]

On Thu, 23 Jun 2011 15:22:46 -0700, Carl Worth  wrote:
> On Sat, 04 Jun 2011 00:22:04 +0400, Dmitry Kurochkin  gmail.com> wrote:
> > On Fri, 03 Jun 2011 13:05:00 -0700, Carl Worth  wrote:
> > > > I do not think we need a test for this fix.  What we need are tests for
> > > > FCC functionality when notmuch-fcc-dirs is a list.
> > > 
> > > Yes!
> 
> I've written these now. And they do test this fix. What they show is
> that a legitimate setting (of notmuch-fcc-dirs as a list) was resulting
> in an error rather than working. That's a nasty little bug, (and poor
> coverage from our test suite before.
> 
> >   Fix wrong-type-argument lisp error in `notmuch-fcc-header-setup' when
> >   `notmuch-fcc-dirs' is set to a list.  The error was in the
> >   `notmuch-fcc-dirs' format check which was changed in an incompatible
> >   way from 0.4 to 0.5.
> 
> Thanks for the fixed wording. I've now pushed out the fix (along with
> the tests).
> 
> With all the talk of "old style" vs. "new style" I was thinking that the
> bug only affected people with the old-style FCC setting. The bug is much
> worse than that, (preventing people from using the new list-based
> style).
> 
> Anyway, thanks for the patch, Dmitry. And thanks for pushing me to take
> another look.
> 

Well, I should have prepared a better commit message from the
beginning.  Then no pushing might have been needed :)

Regards,
  Dmitry

> David, I suggest including this fix (and its test) in the release
> branch.
> 
> -Carl
> 
> -- 
> carl.d.worth at intel.com

Re: [RFC][PATCH] tags_to_maildir_flags: Add option to not move messages from new/ to cur/

[Austin Clements]

Welcome to notmuch!

From your description, I assume you're using both notmuch and another
MUA simultaneously.  I'm betting that MUA is mutt (though please
correct me if I'm wrong).

Unfortunately, mutt's interpretation of maildir doesn't agree with the
rest of the world.  I don't know of any other MUA that exposes the
distinction between mail in the new directory and mail in the old
directory (at least Dovecot, Evolution, Gnus, Kmail, and of course
notmuch don't).  In other MUA's, any mail in the new directory is
immediately moved to cur and new mail is simply anything without
the seen flag.  mutt, on the other hand, only considers mail in the
new directory to be new.

While the maildir specification is a little vague, it strongly implies
two things that mutt's approach violates: mail should never move from
cur to new, and only mail in cur can have flags [1].  While it
never states it outright, the philosophy is that new is simply a
staging ground for incoming mail, not a user-visible state (and
certainly not user-manipulable).

Because of this, I don't think notmuch is the right place to change
this (certainly not in a way that would also violate the spec).  Could
you elaborate a bit on your workflow?  (In particular, are you using
mutt's distinction between new and old?)  Maybe we can find an
alternate solution.

[1] There's a bug open about the second problem (thanks to ccxCZ for
finding this):
http://dev.mutt.org/trac/ticket/2476
Of course, fixing that implies addressing the first problem, too.

On Thu, Jun 23, 2011 at 11:36 AM, Louis Rilling l.rill...@av7.net wrote:
 notmuch_message_tags_to_maildir_flags() moves messages from maildir directory
 new/ to maildir directory cur/, which makes messages lose their new 
 status
 in the MUA. However some users want to keep this new status after, for
 instance, an auto-tagging of new messages.

 This patch introduces notmuch_message_tags_to_maildir_flags_preserve(), which
 does the same job as notmuch_message_tags_to_maildir_flags() except moving
 from maildir new/ to maildir cur/. A new option preserve_new is
 introduced in [maildir] section of .notmuch-config, so that users can
 configure whether commands notmuch tag and notmuch restore preserve the
 new status or not.

 Signed-off-by: Louis Rilling l.rill...@av7.net
 ---
 Hi,

 I'm in the process of using notmuch, but the issue addressed by this patch
 would make me change my habits a bit too fast. I use the new status for
 quickly checking (often without reading) which emails I just received,
 implementing some kind of context/mood/daytime-dependent quick filtering. I'd
 also like to run a pre-tagging script automatically when synchronizing
 periodically (and automatically too) my mailboxes. But the current behavior of
 notmuch tag makes me lose my quick filtering ability.

 This patch is mostly written for discussion. It is certainly not polished 
 (API,
 ABI, bindings) and not tested at all. In particular, I know that there are 
 some
 plans to customize flags synchronization, but I don't know how the library API
 could/should be impacted.

 Thanks for your comments!

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

Notmuch scripts

[ccx]

Hello list!

As some of you know I have written several scripts that aid using
notmuch, including an alternative to the notmuch-mutt perl script.

Since Carl Worth consented to include them into official distribution
I am now cleaning them up, writing docs and extending it so it covers
all features notmuch-mutt currently has.

They can currently be obtained by:
bzr branch http://webprojekty.cz/ccx/bzr/zmuch
Or you can browse the code at:
http://webprojekty.cz/ccx/loggerhead/zmuch/files

During the process of polishing the scripts I thought about few things
that may be interesting to other people integrating notmuch, so let me
hear your opinions. :-)

$NOTMUCH and proxies:
There are applications (whether full-blown interfaces or simple scripts)
that use notmuch. There are scrips that work as proxies to actual
notmuch, eg. by invoking ssh to a machine where the mails are, or
processing the argument list and expanding saved searches. Therefore it
would be very practical if the path to actual executable would be
configurable. Thus I propose:

  * Every application that does not act as a proxy should use
environment variable NOTMUCH to find the actual notmuch executable.
If not defined or empty, just execute 'notmuch' as usual.

  * Every application that acts as a proxy should ignore the NOTMUCH
variable, instead it should be configurable in other way
(configuration file or something easily changeable). This way
chaining of proxies will be possible.

Configuration and temporary files:
I like XDG specification. I think it's bit unnecessary to have to have
config files that belong only to few scripts littered all around my
homedir. Also I think it's reasonable that user would be able to specify
where to put the temporary files. That said atm I have ~/.zmuch as the
only config file, as it felt bit weird to create new directory for just
one file. But as I'm preparing the scripts I see more and more things
that are specific to my setup and I would like them to be configurable.
These are:

  * Spam filter. Do you guys use any? What does it's interface look like?
I currently use bsfilter which I've found does it's job pretty well.

  * Colors. I use bright fg on dark bg, but I understand somebody won't
be happy with this choice.

  * 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? :-)

Thanks for notmuch! I look forward to your responses.
Jan Pobrislo (ccxCZ@freenode)


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

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

[Carl Worth]

On Fri, 24 Jun 2011 07:53:44 -0300, da...@tethera.net wrote:
 From: David Bremner brem...@debian.org

Hi David,

Thanks for the fix. A couple of nit-picky comments on the commit itself
first:

 - c0961e6 introduced a missing slash and
 - cdf1c70a created a file and neglected to add it to clean

I'd put a little more detail in the commit message here:

- c0961e6 introduced a missing slash $(dir)$(LIBNAME)
- cdf1c70a created $(dir)/notmuch.h.gch and neglected to add it to clean

 The former seems to have been harmless, so maybe someone (Carl?) can
 check if $(dir)/$(LIBNAME) really needs to be removed?

This auxiliary text should be below the --- line in the email so that
it won't be in the commit message after I do git am. (As is, I'd have
to do extra work to git commit --amend this text away).

As for the actual question, yes, $(dir)/$(LIBNAME) is supposed to be
cleaned and is not getting cleaned. I've got libnotmuch.so.1.{1,2,3,4}.0
all sitting around never cleaned.

 -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) libnotmuch.a notmuch.aux notmuch.sym 

Meanwhile, I notice now that libnotmuch.a is also wrong, (should be
$(dir)/libnotmuch.a).

Clearly we could use some testing of our make clean target to ensure
it actually works. Does the Debian stuff not test anything like this?
(Maybe I'm thinking of typical testing done by autoconf/automake's make
distcheck that we haven't replicated yet.)

-Carl

-- 
carl.d.wo...@intel.com


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

Re: Notmuch scripts

[Carl Worth]

On Fri, 24 Jun 2011 13:28:21 +0200, c...@te2000.cz wrote:
 As some of you know I have written several scripts that aid using
 notmuch, including an alternative to the notmuch-mutt perl script.

Thanks for sharing these, Jan!

 Since Carl Worth consented to include them into official distribution
 I am now cleaning them up, writing docs and extending it so it covers
 all features notmuch-mutt currently has.
...
 Or you can browse the code at:
   http://webprojekty.cz/ccx/loggerhead/zmuch/files

It's been interesting for me to read through the README here.

So much of the new functionality here consists of things I'd love to
have implemented in the core command-line interface of notmuch, (I
always have wanted it to be useful for direct command-line interaction
by a human). Some of these features I think have even be implemented
previously by Austin through his custom query parser.

The features I see that I'd really like to see in the core notmuch
command-line tool are:

* Configurable saved searches, (a syntax for expanding aliases
  for often-repeated search specifications).

  That's an idea we've had for a while. What's new with the
  zmuch implementation is the proposal of :alias for the
  syntax. I think I might like that quite a bit. It looks a bit
  easier to read (and type) than the previously-proposed
  {alias}.

* Delivery of search results to a maildir of symlinks

  The zmuch implementation has this functionality intertwined
  with something that also invokes mutt. Obviously, people using
  other MUAs might like to access this feature independently.

  I think I'd like to see this as:

notmuch search --format=maildir:/path/to/directory

* Operations on files matching search terms (move, remove,
  xargs)

  This isn't an operation I'd previously considered including in
  notmuch, but it does seem generally quite useful.

  Should we consider doing something like git does and allow
  something like notmuch xargs simply find and invoke a shell
  script named notmuch-xargs?

  Doing that could let us get a bunch of this functionality in
  place in the core sooner than if we waited for it to be
  re-implemented in C.

  Though if we did this, I think I'd be highly inclined to port
  the scripts from zsh to bash or even POSIX sh. How hard would
  that be?

* Better date syntax for search specifications

  That's something that's obviously been missing from notmuch
  core from the beginning. And there have been several proposals
  with patches to do this in various ways.

* Implicit concatenation of search terms with OR

  This seems like something easy to do with a command-line
  arguemnt. Perhaps notmuch search --or ... ?

If we got all that into the core, then what would be left here would be:

notmuch-mailvars.sh
notmuch-mutt.sh

These would provide integration of notmuch with mutt.

notmuch-spam.sh
notmuch-unspam.sh

These would provide integration of notmuch with
bsfilter, (and perhaps should be named to make that more
clear---or generalized to justify the current name).

notmuch-pager.sh

I haven't looked at this to see what the colorization
actually looks like, (I'm not always a huge fan of lots
of color in my terminals). It seems that this would be
more cleanly implemented as notmuch-colorize.sh or so
and leave the pagination separate.

If we had that, I'd feel really comfortable having each of those in
contrib. I think contrib should be restricted to things which provide
integration of notmuch with some external tool, (and should make that
obvious by having a name like notmuch-tool or notmuch-tool.sh or
whatever).

All in all, there's definitely some very interesting functionality here,
and I definitely appreciate you sharing it. Let's figure out the best
way to get it all integrated into notmuch.

Maybe in the meantime we throw everything into contrib even if some of
it is seen as just proposals for better interfaces in the core tool? I
don't know.

   * Every application that does not act as a proxy should use
 environment variable NOTMUCH to find the actual notmuch executable.
 
   * Every application that acts as a proxy should ignore the NOTMUCH
   variable

That sounds reasonable enough to me. Perhaps these rules could go into a
new contrib/README that would set out some guidelines for writing
contrib tools, (such as notmuch-tool which I mentioned above).

 Configuration and temporary files:
 I like XDG specification.

I'm missing some context to know what you're suggesting here.

 I think it's bit unnecessary to have to have
 

Re: [PATCH] fix sum moar typos

[Pieter Praet]

On Thu, 23 Jun 2011 16:22:27 -0700, Carl Worth cwo...@cworth.org wrote:
Non-text part: multipart/signed
 On Mon, 20 Jun 2011 22:14:21 +0200, Pieter Praet pie...@praet.org wrote:
  Various typo fixes in docs, docstrings, comments, etc...
  
  Signed-off-by: Pieter Praet pie...@praet.org
 
 Thanks for these fixes, Pieter!

My pleasure.

 I've pushed these all out now. I split the original commit up into 6
 commits that each touch different kinds of text, (non-code text files,
 comments within source files, error messages within source files, etc.)
 
 The idea there is that these different kinds of text have different
 potential impacts on the correctness of the code. So some release
 manager might be willing to include one kind of change, but not another,
 for example.

Agreed.

 Also, it made things a bit easier to read. There were two incorrect typo
 fixes in the original commit which I fixed:
 
  -\tSeveral notmuch commands accept a comman syntax for search\n
  +\tSeveral notmuch commands accept a command syntax for search\n
 
 This is now common syntax.
 
  -# Remember stdout and stderr file descriptios and redirect test
  +# Remember stdout and stderr file descriptions and redirect test
 
 This is now file descriptors.
 
 And one change where I left the original text unchanged:
 
* A non-NULL return value is guaranteed to be a valid string pointer
* pointing to the characters new/ or cur/, (but not
  - * NUL-terminated).
  + * NULL-terminated).
 
 This comment uses NULL to describe a NULL pointer and NUL to
 describe the ASCII character '\0'. (I know that NUL is a really
 annoying historically misspelled abbreviation, but it is in standard
 usage I believe---see ASCII(7) for example.)

Prime examples of or even made some new ones [1] :D

 Meanwhile, I was almost tempted to leave this misspelling unchanged:
 
  -(error %s is a file. Can't creat maildir. path))
  +(error %s is a file. Can't create maildir. path))
 
 Since that's also a classic historically misspelled abbreviation. ;-)
 
 Oh, and let me just thank you for being so thorough! There were several
 fixes you made that could obviously not be caught by an automated spell
 checker:
 
  ---part=id, (David Edmonson wants to rewrite some of notmuch show to
  +--part=id, (David Edmondson wants to rewrite some of notmuch show to
 ...
   (defun notmuch-user-other-email ()
  -  Return the user.primary_email value (as a list) from the notmuch 
  configuration.
  +  Return the user.other_email value (as a list) from the notmuch 
  configuration.
 ...
   (defcustom notmuch-after-tag-hook nil
  -  Hooks that are run before tags of a message are modified.
  +  Hooks that are run after tags of a message are modified.
 ...
  -The debian packaging exists in the top-level debian directory within
  +The Debian packaging exists in the top-level debian directory within
 
 Those all demonstrate a particular eye for detail—well done! For a
 couple of those, I almost gave them their own commits.
 
 In passing, let me point out the most amusing typo I saw in the patch:
 
  -} /* Appleasing Emacs */
  +} /* Appeasing Emacs */
 
 I almost hate to see that go, because I like the pleasing portmanteau
 sound of appleasing. Please applease me and leave this pleasing typo?
 
 Admittedly, that's not in code that's originally mine, so I can't say it
 wasn't intentional either.
 
 Finally, *many* of the typos and misspellings were originally mine. It's
 certainly embarrassing to see so many (and so many repeats). It was also
 embarrassing to see how many misspellings I committed while typing the
 commit messages, (fortunately I rebased many away).

Let's turn that around:

Comments and commit messages are (understandably) a mere afterthought
for most coders, including myself, and are thus often very terse or
even nonexistent, which automatically translates to less typos (y=kx).

You however, seem to be incredibly disciplined in this respect,
so statistically speaking, you're destined to become typo-king,
and you have every reason to be *proud* of it. :D

The only thing you could possibly have to be embarrassed about,
is insufficient laziness (which, for programmers, is considered a
virtue) ;)

 And now I'm starting to get paranoid about this message. Am I really
 brave enough to type words like embarrassing, misspelling, and
 committed here?
 
 Thanks again,
 
 -Carl
Non-text part: application/pgp-signature


Peace

-- 
Pieter


[1] id:1307202852-4398-1-git-send-email-pie...@praet.org
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [RFC][PATCH] tags_to_maildir_flags: Add option to not move messages from new/ to cur/

[Louis Rilling]

On 24/06/11 11:19 -0400, Austin Clements wrote:
 Welcome to notmuch!

Thanks!

 
 From your description, I assume you're using both notmuch and another
 MUA simultaneously.  I'm betting that MUA is mutt (though please
 correct me if I'm wrong).

Correct :)

 
 Unfortunately, mutt's interpretation of maildir doesn't agree with the
 rest of the world.  I don't know of any other MUA that exposes the
 distinction between mail in the new directory and mail in the old
 directory (at least Dovecot, Evolution, Gnus, Kmail, and of course
 notmuch don't).  In other MUA's, any mail in the new directory is
 immediately moved to cur and new mail is simply anything without
 the seen flag.  mutt, on the other hand, only considers mail in the
 new directory to be new.
 
 While the maildir specification is a little vague, it strongly implies
 two things that mutt's approach violates: mail should never move from
 cur to new, and only mail in cur can have flags [1].  While it
 never states it outright, the philosophy is that new is simply a
 staging ground for incoming mail, not a user-visible state (and
 certainly not user-manipulable).

Thanks for the detailed explanation.

 
 Because of this, I don't think notmuch is the right place to change
 this (certainly not in a way that would also violate the spec).  Could
 you elaborate a bit on your workflow?  (In particular, are you using
 mutt's distinction between new and old?)  Maybe we can find an
 alternate solution.

Yes my quick mood-dependent filtering just acts on new (as shown by mutt)
mails, while old mails are kept until either 1) they can be read (yes, this
happens!), or 2) they can be archived (because they might be interesting in
some future), or 3) they can be deleted (eg. became too old to be worth
reading them).

However, I don't think that I need the violating behavior of mutt: new mails
are just new, not replied to/read, or anything else. The only rare cases in
which I may set back the new flag are when I mistakenly start reading an email
(wrong keystroke most of the time). Even in that case, I don't care if the mail
becomes old (ie moves to cur/).

Maybe the alternate solution could consist in simply not renaming emails having
no flags to be changed (Currently notmuch_message_tags_to_maildir_flags()
unconditionally moves messages from new/ to cur/). This would even lead to a
shorter patch :) Do you think that this would be acceptable?

Thanks,

Louis

 
 [1] There's a bug open about the second problem (thanks to ccxCZ for
 finding this):
 http://dev.mutt.org/trac/ticket/2476
 Of course, fixing that implies addressing the first problem, too.
 
 On Thu, Jun 23, 2011 at 11:36 AM, Louis Rilling l.rill...@av7.net wrote:
  notmuch_message_tags_to_maildir_flags() moves messages from maildir 
  directory
  new/ to maildir directory cur/, which makes messages lose their new 
  status
  in the MUA. However some users want to keep this new status after, for
  instance, an auto-tagging of new messages.
 
  This patch introduces notmuch_message_tags_to_maildir_flags_preserve(), 
  which
  does the same job as notmuch_message_tags_to_maildir_flags() except moving
  from maildir new/ to maildir cur/. A new option preserve_new is
  introduced in [maildir] section of .notmuch-config, so that users can
  configure whether commands notmuch tag and notmuch restore preserve the
  new status or not.
 
  Signed-off-by: Louis Rilling l.rill...@av7.net
  ---
  Hi,
 
  I'm in the process of using notmuch, but the issue addressed by this patch
  would make me change my habits a bit too fast. I use the new status for
  quickly checking (often without reading) which emails I just received,
  implementing some kind of context/mood/daytime-dependent quick filtering. 
  I'd
  also like to run a pre-tagging script automatically when synchronizing
  periodically (and automatically too) my mailboxes. But the current behavior 
  of
  notmuch tag makes me lose my quick filtering ability.
 
  This patch is mostly written for discussion. It is certainly not polished 
  (API,
  ABI, bindings) and not tested at all. In particular, I know that there are 
  some
  plans to customize flags synchronization, but I don't know how the library 
  API
  could/should be impacted.
 
  Thanks for your comments!
 
  Louis
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch