Re: [PATCH] allow to not sort the search results

[Olly Betts]

On Fri, Apr 16, 2010 at 08:37:04AM +0200, Sebastian Spaeth wrote:
> On 2010-04-15, Olly Betts wrote:
> > Also, sorting by relevance requires more calculations and may require
> > fetching additional data (document length for example).
> > 
> > So I think it would make sense for --sort=relevance and --sort=unsorted to
> > be separate options.
> 
> Now I am a bit confused. The API docs state that sort_by_relevance is
> the default. So by skipping any sort_by_value() will that incur the additional
> calculations (with our BoolWeight set?). All I want is the fasted way
> to return a searched set of docs :-).

Yes, sort_by_relevance() is the default.  But if you set BoolWeight as the
weighting scheme then the relevance is simply zero, and Xapian doesn't have
to fetch any statistics and calculate a score from them.  When documents
have exactly equal relevance weight, then the docid order is used.  So
although sort_by_relevance() is technically still on with BoolWeight, by
"sorting by relevance" I wasn't talking about this case.

So --sort=unsorted and --sort=relevance would only differ in code by the former
setting BoolWeight and the latter not.

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

[PATCH 3/3] notmuch-tag: don't sort messages before applying tag changes

[Sebastian Spaeth]

It's not neccessary to sort the results before we apply tags. Xapian
contributor Olly Betts says that savings might be bigger with a cold
file cache and (as unsorted implies really sorted by document id) a better
cache locality when applying tags to messages.

Signed-off-by: Sebastian Spaeth 
---
 notmuch-tag.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/notmuch-tag.c b/notmuch-tag.c
index 8b6f7dc..fd54bc7 100644
--- a/notmuch-tag.c
+++ b/notmuch-tag.c
@@ -107,6 +107,9 @@ notmuch_tag_command (void *ctx, unused (int argc), unused 
(char *argv[]))
return 1;
 }
 
+/* tagging is not interested in any special sort order */
+notmuch_query_set_sort (query, NOTMUCH_SORT_UNSORTED);
+
 for (messages = notmuch_query_search_messages (query);
 notmuch_messages_valid (messages) && !interrupted;
 notmuch_messages_move_to_next (messages))
-- 
1.7.0.4

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

[PATCH 2/3] notmuch-search: Introduce --sort=unsorted

[Sebastian Spaeth]

In some cases, we might not be interested in any special sort order, so
this introduces a --sort=unsorted command line option together with its
documentation.

Signed-off-by: Sebastian Spaeth 
---
 notmuch-search.c |2 ++
 notmuch.1|   10 ++
 notmuch.c|7 ---
 3 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/notmuch-search.c b/notmuch-search.c
index 4e3514b..854a9ae 100644
--- a/notmuch-search.c
+++ b/notmuch-search.c
@@ -217,6 +217,8 @@ notmuch_search_command (void *ctx, int argc, char *argv[])
sort = NOTMUCH_SORT_OLDEST_FIRST;
} else if (strcmp (opt, "newest-first") == 0) {
sort = NOTMUCH_SORT_NEWEST_FIRST;
+   } else if (strcmp (opt, "unsorted") == 0) {
+   sort = NOTMUCH_SORT_UNSORTED;
} else {
fprintf (stderr, "Invalid value for --sort: %s\n", opt);
return 1;
diff --git a/notmuch.1 b/notmuch.1
index 86830f4..6d4beaf 100644
--- a/notmuch.1
+++ b/notmuch.1
@@ -152,12 +152,14 @@ Presents the results in either JSON or plain-text 
(default).
 .RE
 .RS 4
 .TP 4
-.BR \-\-sort= ( newest\-first | oldest\-first )
+.BR \-\-sort= ( newest\-first | oldest\-first | unsorted)
 
 This option can be used to present results in either chronological order
-.RB ( oldest\-first )
-or reverse chronological order
-.RB ( newest\-first ).
+.RB ( oldest\-first ),
+reverse chronological order
+.RB ( newest\-first )
+or without any defined sort order
+.RB ( unsorted ).
 
 Note: The thread order will be distinct between these two options
 (beyond being simply reversed). When sorting by
diff --git a/notmuch.c b/notmuch.c
index dcfda32..e31dd88 100644
--- a/notmuch.c
+++ b/notmuch.c
@@ -165,11 +165,12 @@ command_t commands[] = {
   "\t\tPresents the results in either JSON or\n"
   "\t\tplain-text (default)\n"
   "\n"
-  "\t--sort=(newest-first|oldest-first)\n"
+  "\t--sort=(newest-first|oldest-first|unsorted)\n"
   "\n"
   "\t\tPresent results in either chronological order\n"
-  "\t\t(oldest-first) or reverse chronological order\n"
-  "\t\t(newest-first), which is the default.\n"
+  "\t\t(oldest-first),reverse chronological order\n"
+  "\t\t(newest-first), which is the default or\n"
+  "\t\t(unsorted) without any special sort order.\n"
   "\n"
   "\tSee \"notmuch help search-terms\" for details of the search\n"
   "\tterms syntax." },
-- 
1.7.0.4

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

[PATCH 1/3] query.cc: allow to return query results unsorted

[Sebastian Spaeth]

Previously, we always sorted the returned results by some string value,
(newest-to-oldest by default), however in some cases (as when applying
tags to a search result) we are not interested in any special order.

This introduces a NOTMUCH_SORT_UNSORTED value that does just that. It is
not used at the moment anywhere in the code.

Signed-off-by: Sebastian Spaeth 
---
 lib/notmuch.h |3 ++-
 lib/query.cc  |2 ++
 2 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/lib/notmuch.h b/lib/notmuch.h
index a7e66dd..bae48a6 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -346,7 +346,8 @@ notmuch_query_create (notmuch_database_t *database,
 typedef enum {
 NOTMUCH_SORT_OLDEST_FIRST,
 NOTMUCH_SORT_NEWEST_FIRST,
-NOTMUCH_SORT_MESSAGE_ID
+NOTMUCH_SORT_MESSAGE_ID,
+NOTMUCH_SORT_UNSORTED
 } notmuch_sort_t;
 
 /* Specify the sorting desired for this query. */
diff --git a/lib/query.cc b/lib/query.cc
index 10f8dc8..4148f9b 100644
--- a/lib/query.cc
+++ b/lib/query.cc
@@ -148,6 +148,8 @@ notmuch_query_search_messages (notmuch_query_t *query)
case NOTMUCH_SORT_MESSAGE_ID:
enquire.set_sort_by_value (NOTMUCH_VALUE_MESSAGE_ID, FALSE);
break;
+case NOTMUCH_SORT_UNSORTED:
+   break;
}
 
 #if DEBUG_QUERY
-- 
1.7.0.4

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

Re: [PATCH] allow to not sort the search results

[Sebastian Spaeth]

On 2010-04-15, Olly Betts wrote:
 
> > I would be happy to have it called --sort=relevance too, the unsorted
> > points out potential performance improvements a bit better, IMHO
> > (although they seem to be really small with a warm cache).
> 
> When using the results of a search to add/remove tags, there's likely to be
> an additional win from --sort=unsorted as documents will now be processed
> in docid order which will tend to have a more cache friendly locality of
> access.

Olly was right in that even for "notmuch tag" we were sorting the
results by date before applying tag changes. I have slightly reworked my
patch to have notmuch tag avoid doing that. I also split up the patch in
3 patches that do one thing each.

The patches do:
1: Introduce NOTMUCH_SORT_UNSORTED
2: Introduce notmuch search --sort=unsorted
3: Make notmuch tag not sort results by date

#2 is the one I am least sure about, I don't know if there is a use case
for notmuch search returning unsorted results. But 1 & 3 are useful at
least.
 
> Also, sorting by relevance requires more calculations and may require fetching
> additional data (document length for example).
> 
> So I think it would make sense for --sort=relevance and --sort=unsorted to be
> separate options.

Now I am a bit confused. The API docs state that sort_by_relevance is
the default. So by skipping any sort_by_value() will that incur the additional
calculations (with our BoolWeight set?). All I want is the fasted way
to return a searched set of docs :-).

Patches 1-3 follow as reply to this one
Sebastian
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] add a number of new feature ideas to TODO file

[Dirk Hohndel]

Signed-off-by: Dirk Hohndel 
---
 TODO |   45 +
 1 files changed, 45 insertions(+), 0 deletions(-)

diff --git a/TODO b/TODO
index 14c5fd0..226f243 100644
--- a/TODO
+++ b/TODO
@@ -56,6 +56,24 @@ Change 'a' command in thread-view mode to only archive open 
messages.
 
 Add a binding to open all closed messages.
 
+Add 'd' keybinding that works like 'a' plus adds a +deleted tag
+
+Add 'D' keybinding that does the same in search view, but in thread
+show mode marks the whole thread as deleted
+
+Add '???' keybinding that skips the current thread without archiving
+it
+
+Add notmuch-message mode that allows us to override many of the
+default behaviors of emacs message mode without affecting people using
+messages mode from elsewhere (e.g., gnus). This would allow us to add
+- selection of from address (with configured email addresses as default 
choices to pick from
+- set user-agent string
+
+Allow differen "real names" for the "other_email" addresses; I
+envision an "other_names" parameter; if unset all email addresses use
+the same name, otherwise the two lists are matched
+
 Emacs saved-search interface
 
 Here's a proposal Carl wrote (id:87einafy4u@yoom.home.cworth.org):
@@ -245,6 +263,21 @@ of multiple searches. For example, I would like to do:
 See id:3wdpr282yz2@testarossa.amd.com for more details on the
 use cases of the above.
 
+Allow anchors in searches:
+
+ notmuch search from:domain.org$ only matches if "domain.org" is
+ at the end of the From: header
+
+ notmuch search from:^username only matches if "username" is at
+ the beginning of the From: header (right after the ':')
+
+ This leaves the interesting question if we want a way to bind to
+ the actual address component.
+
+Add Received: header to the indexed header components
+
+Add folder keyword
+
 Database changes
 
 Store a reference term for every message-id that appears in
@@ -285,3 +318,15 @@ Audit everything for dealing with out-of-memory (and drop 
xutil.c).
 
 Investigate why the notmuch database is slightly larger than the sup
 database for the same corpus of email.
+
+Thirdparty apps
+---
+(not sure this is the best spot to collect requests like this)
+
+notmuchsync
+
+Add feature to move files in the maildir hierarchy
+
+ notmuchsync --move "searchstring" "targetfolder"
+ Where searchstring is any valid notmuch search
+
-- 
1.6.6.1


-- 
Dirk Hohndel
Intel Open Source Technology Center
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] add a number of new feature ideas to TODO file

[Dirk Hohndel]

Signed-off-by: Dirk Hohndel 
---
 TODO |   45 +
 1 files changed, 45 insertions(+), 0 deletions(-)

diff --git a/TODO b/TODO
index 14c5fd0..226f243 100644
--- a/TODO
+++ b/TODO
@@ -56,6 +56,24 @@ Change 'a' command in thread-view mode to only archive open 
messages.

 Add a binding to open all closed messages.

+Add 'd' keybinding that works like 'a' plus adds a +deleted tag
+
+Add 'D' keybinding that does the same in search view, but in thread
+show mode marks the whole thread as deleted
+
+Add '???' keybinding that skips the current thread without archiving
+it
+
+Add notmuch-message mode that allows us to override many of the
+default behaviors of emacs message mode without affecting people using
+messages mode from elsewhere (e.g., gnus). This would allow us to add
+- selection of from address (with configured email addresses as default 
choices to pick from
+- set user-agent string
+
+Allow differen "real names" for the "other_email" addresses; I
+envision an "other_names" parameter; if unset all email addresses use
+the same name, otherwise the two lists are matched
+
 Emacs saved-search interface
 
 Here's a proposal Carl wrote (id:87einafy4u.fsf at yoom.home.cworth.org):
@@ -245,6 +263,21 @@ of multiple searches. For example, I would like to do:
 See id:3wdpr282yz2.fsf at testarossa.amd.com for more details on the
 use cases of the above.

+Allow anchors in searches:
+
+ notmuch search from:domain.org$ only matches if "domain.org" is
+ at the end of the From: header
+
+ notmuch search from:^username only matches if "username" is at
+ the beginning of the From: header (right after the ':')
+
+ This leaves the interesting question if we want a way to bind to
+ the actual address component.
+
+Add Received: header to the indexed header components
+
+Add folder keyword
+
 Database changes
 
 Store a reference term for every message-id that appears in
@@ -285,3 +318,15 @@ Audit everything for dealing with out-of-memory (and drop 
xutil.c).

 Investigate why the notmuch database is slightly larger than the sup
 database for the same corpus of email.
+
+Thirdparty apps
+---
+(not sure this is the best spot to collect requests like this)
+
+notmuchsync
+
+Add feature to move files in the maildir hierarchy
+
+ notmuchsync --move "searchstring" "targetfolder"
+ Where searchstring is any valid notmuch search
+
-- 
1.6.6.1


-- 
Dirk Hohndel
Intel Open Source Technology Center

Re: [PATCH] configure: Fix syntax error (spaces in assignment).

[Carl Worth]

On Thu, 15 Apr 2010 11:51:47 +0200, Gregor Hoffleit  wrote:
> Before and after the assignment operator, no spaces are allowed.
> I don't know if there are any /bin/sh which allow spaces, but at least
> in bash, csh and zsh, the former code was no valid assigment.

Thanks, Gregor.

I went through all the work to try to make the over-linking conditional,
and then only tested carefully on OS X, (not noticing that I'd broken
the Linux case just as much as if I had accepted the unconditional
version).

This is pushed now.

-Carl


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

[PATCH] configure: Fix syntax error (spaces in assignment).

[Carl Worth]

On Thu, 15 Apr 2010 11:51:47 +0200, Gregor Hoffleit  
wrote:
> Before and after the assignment operator, no spaces are allowed.
> I don't know if there are any /bin/sh which allow spaces, but at least
> in bash, csh and zsh, the former code was no valid assigment.

Thanks, Gregor.

I went through all the work to try to make the over-linking conditional,
and then only tested carefully on OS X, (not noticing that I'd broken
the Linux case just as much as if I had accepted the unconditional
version).

This is pushed now.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100415/5d0e75f5/attachment.pgp>

[PATCH] configure: Add support for GMime 2.6

[Adrien Bustany]

Notmuch compiles just fine with GMime 2.6, so accept it in the configure
script.
---
 configure |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index eebe075..d4d462f 100755
--- a/configure
+++ b/configure
@@ -188,6 +188,11 @@ if pkg-config --modversion gmime-2.4 > /dev/null 2>&1; then
 have_gmime=1
 gmime_cflags=$(pkg-config --cflags gmime-2.4)
 gmime_ldflags=$(pkg-config --libs gmime-2.4)
+elif pkg-config --modversion gmime-2.6 > /dev/null 2>&1; then
+printf "Yes.\n"
+have_gmime=1
+gmime_cflags=$(pkg-config --cflags gmime-2.6)
+gmime_ldflags=$(pkg-config --libs gmime-2.6)
 else
 printf "No.\n"
 have_gmime=0
-- 
1.7.0.1

Re: The archive operation should only archive open messages

[Carl Worth]

On Thu, 15 Apr 2010 14:07:37 -0700, Dirk Hohndel  wrote:
> I am always confused about the behavior of 'a' - does it archive the
> current message? Or the current thread? Or the current thread down to
> where I am? Or (as you propose) just the open messages?
> 
> I think we really need to spend some time to crsiply define the
> semantics of these commands.

I think the semantics have always been specified well, and
documented. Have you hit the '?' key to get a brief description of all
of the key bindings? Then you can also run `describe-key' ("C-h k" by
default) and then press a key to get even more thorough documentation.

If anything is not crisp enough there, please let me know and we'll fix
it right away.

I do agree that it's important for us to discuss what the ideal set of
operations is, and I don't claim that we have anything close to that in
the current implementation.

So that's why we're here talking I think. :-)

-Carl


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

The archive operation should only archive open messages

[Carl Worth]

On Thu, 15 Apr 2010 14:07:37 -0700, Dirk Hohndel  
wrote:
> I am always confused about the behavior of 'a' - does it archive the
> current message? Or the current thread? Or the current thread down to
> where I am? Or (as you propose) just the open messages?
> 
> I think we really need to spend some time to crsiply define the
> semantics of these commands.

I think the semantics have always been specified well, and
documented. Have you hit the '?' key to get a brief description of all
of the key bindings? Then you can also run `describe-key' ("C-h k" by
default) and then press a key to get even more thorough documentation.

If anything is not crisp enough there, please let me know and we'll fix
it right away.

I do agree that it's important for us to discuss what the ideal set of
operations is, and I don't claim that we have anything close to that in
the current implementation.

So that's why we're here talking I think. :-)

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100415/e2e20018/attachment.pgp>

Re: [notmuch] Bulk message tagging

[Carl Worth]

On Thu, 15 Apr 2010 16:04:38 -0400, Jesse Rosenthal  wrote:
> On Wed, 14 Apr 2010 17:59:01 -0700, Carl Worth  wrote:
> > We could fix all[*] the bugs of "*" by changing it to simply call the
> > new region-based tagging function. The only concern I have with that is
> > that it might be significantly slower, (it will execute N "notmuch tag"
> > commands to tag the N threads in the current buffer, rather than just
> > one "notmuch tag" command with the same search).
> 
> Not quite true: the region command only executes one "notmuch tag"
> command over "id:X or id:Y or id:Z or ...". 

Oh, I see. Sorry for my misunderstanding.

So that is more efficient in that regard.

But it also does mean that this operation is all set up to run into
"argument list too long" errors.

We'll probably need to arrange for notmuch to accept search
specifications on stdin or so.

-Carl


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

[notmuch] Bulk message tagging

[Carl Worth]

On Thu, 15 Apr 2010 16:04:38 -0400, Jesse Rosenthal  
wrote:
> On Wed, 14 Apr 2010 17:59:01 -0700, Carl Worth  wrote:
> > We could fix all[*] the bugs of "*" by changing it to simply call the
> > new region-based tagging function. The only concern I have with that is
> > that it might be significantly slower, (it will execute N "notmuch tag"
> > commands to tag the N threads in the current buffer, rather than just
> > one "notmuch tag" command with the same search).
> 
> Not quite true: the region command only executes one "notmuch tag"
> command over "id:X or id:Y or id:Z or ...". 

Oh, I see. Sorry for my misunderstanding.

So that is more efficient in that regard.

But it also does mean that this operation is all set up to run into
"argument list too long" errors.

We'll probably need to arrange for notmuch to accept search
specifications on stdin or so.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100415/726d72f7/attachment.pgp>

"bouncing" messages

[Jameson Rollins]

Does anyone know how to "bounce" a message, in the mutt sense of the
term where the message is send unaltered to a new recipient, in
notmuch/emacs?  I can't find any way to do it with message-mode.  I
think this was very useful feature in mutt, and it would be great if we
could add a command to notmuch-show to do the same thing.  Any
suggestions?

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/20100415/0f47bf37/attachment.pgp>

The archive operation should only archive open messages

[Jesse Rosenthal]

On Thu, 15 Apr 2010 13:41:17 -0700, Carl Worth  wrote:
> A bad bug occurs when paging through the thread with the space
> bar. After showing me these few messages, it will then proceed to
> archive *all* the messages in the thread (not only those it showed
> me). And I'm likely to be unaware of this since the closed (but not yet
> archived) messages are not easily distinguished from messages that were
> previously closed and archived.

This actually brings up a behavior that bites me from time to time. I
often mark messages "to-reply", and notmuch colors them red for
me. Then, when I reply to the message, it auto-removes the tag (based on
a message-mode hook I sent to the thread a while back*). I've gotten to
the point where I depend on this behavior.

However, when I have a long thread, and only one message in the inbox,
tagging the thread, of course, tags all the messages in it "to-reply."
Now, the way to do it might be to just change my habits, and only tag
while in show-mode, as opposed to search-mode. But this does seem to be
in conflict with the way I intuitively want to handle my mail, and I
imagine I'm not the only one.

Which is all just to say that I think that archiving is just a special
case of tagging/untagging, and that the issues raised here should be
considered across the larger general case.

[*] id:87pr3iygrx.fsf at jhu.edu

[PATCH] emacs: Re-arrange message sending code

[David Edmondson]

On Thu, 15 Apr 2010 16:50:27 +0100, David Edmondson  wrote:
> Define a new `mail-user-agent' (`notmuch-user-agent') and use it by
> default. Re-arrange various routines that send mail to use this
> (compose, reply, forward). Insert a `User-Agent:' header by default.

I meant to add that this was a proposal in response to Sebastian's
User-Agent related patch (id:87y6gtnkch.fsf at SSpaeth.de).

Setting `mail-user-agent' in notmuch.el is a bit aggressive, but without
requiring some configuration on the part of the user (which Carl
appeared to want to avoid) it's not obvious how to make things as
simple as the existing approach.

dme.
-- 
David Edmondson, http://dme.org

The archive operation should only archive open messages

[Jameson Rollins]

On Thu, 15 Apr 2010 13:41:17 -0700, Carl Worth  wrote:
> Some people will claim (and I've even agreed) that the space bar is too
> magic. But this bug also happens with an explicit command to archive the
> current thread (such as hitting 'a').
>
> I think the fix is to change these commands to only archive the messages
> that are currently open. That will make these operations behave as I
> expect, and I don't think will cause any unexpected or confusing
> behavior. But please let me know if you disagree.

I actually *really* don't like that the space bar does this.  In fact, I
build my own notmuch-show-advance function in a notmuch-hacks.el that I
load to expressly get around this.  The only tag manipulation I want
done automatically is removal of "unread" when I visit a message.  Other
than that, I want to do all tag manipulation manually.  So I would be
thrilled is this "feature" was removed entirely, which would of course
get rid of this bug as well.

> [*] My tag:to-me is set by a script doing "notmuch tag +to-me
> to:cworth at cworth.org or to:carl.d.worth at intel.com ...". I'd prefer this
> to be a saved-search of course---that's one of the patches I haven't had
> a chance to review yet.

I've asked this in the past, but isn't this exactly what notmuch
"folders" are?  Is there a reason you don't just define this search as a
folder?

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/20100415/2a44b143/attachment.pgp>

[PATCH] configure: Add support for GMime 2.6

[Adrien Bustany]

Notmuch compiles just fine with GMime 2.6, so accept it in the configure
script.
---
 configure |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index eebe075..d4d462f 100755
--- a/configure
+++ b/configure
@@ -188,6 +188,11 @@ if pkg-config --modversion gmime-2.4 > /dev/null 2>&1; then
 have_gmime=1
 gmime_cflags=$(pkg-config --cflags gmime-2.4)
 gmime_ldflags=$(pkg-config --libs gmime-2.4)
+elif pkg-config --modversion gmime-2.6 > /dev/null 2>&1; then
+printf "Yes.\n"
+have_gmime=1
+gmime_cflags=$(pkg-config --cflags gmime-2.6)
+gmime_ldflags=$(pkg-config --libs gmime-2.6)
 else
 printf "No.\n"
 have_gmime=0
-- 
1.7.0.1

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

[PATCH] emacs: Re-arrange message sending code

[David Edmondson]

Define a new `mail-user-agent' (`notmuch-user-agent') and use it by
default. Re-arrange various routines that send mail to use this
(compose, reply, forward). Insert a `User-Agent:' header by default.
---
 emacs/notmuch-hello.el |2 +
 emacs/notmuch-mua.el   |   94 
 emacs/notmuch-show.el  |5 ++-
 emacs/notmuch.el   |   43 --
 4 files changed, 130 insertions(+), 14 deletions(-)
 create mode 100644 emacs/notmuch-mua.el

diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index c49a35f..83586f2 100644
--- a/emacs/notmuch-hello.el
+++ b/emacs/notmuch-hello.el
@@ -25,6 +25,7 @@

 (require 'notmuch-lib)
 (require 'notmuch)
+(require 'notmuch-mua)

 (declare-function notmuch-search "notmuch" (query &optional oldest-first 
target-thread target-line))
 (declare-function notmuch-folder-count "notmuch" (search))
@@ -314,6 +315,7 @@ diagonal."

   (use-local-map widget-keymap)
   (local-set-key "=" 'notmuch-hello-update)
+  (local-set-key "m" 'notmuch-mua-mail)
   (local-set-key "q" '(lambda () (interactive) (kill-buffer (current-buffer
   (local-set-key "s" 'notmuch-hello-goto-search)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
new file mode 100644
index 000..c8a8743
--- /dev/null
+++ b/emacs/notmuch-mua.el
@@ -0,0 +1,94 @@
+;; notmuch-mua.el --- emacs style mail-user-agent
+;;
+;; Copyright ?? David Edmondson
+;;
+;; This file is part of Notmuch.
+;;
+;; Notmuch is free software: you can redistribute it and/or modify it
+;; under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+;;
+;; Notmuch is distributed in the hope that it will be useful, but
+;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+;; General Public License for more details.
+;;
+;; You should have received a copy of the GNU General Public License
+;; along with Notmuch.  If not, see .
+;;
+;; Authors: David Edmondson 
+
+(require 'message)
+
+;;
+
+(defcustom notmuch-mua-send-hook '(notmuch-mua-message-send-hook)
+  "Hook run before sending messages."
+  :group 'notmuch
+  :type 'hook)
+
+(defcustom notmuch-mua-user-agent-function 'notmuch-mua-user-agent
+  "Function used to generate a `User-Agent:' string. If this is
+`nil' then no `User-Agent:' will be generated."
+  :group 'notmuch
+  :type 'function)
+
+;;
+
+(defun notmuch-mua-user-agent ()
+  "Generate a `User-Agent:' string suitable for notmuch."
+  (concat
+   ;; Trim off the trailing newline.
+   (substring (shell-command-to-string
+  (concat notmuch-command " --version"))
+ 0 -1)
+   " (Emacs " emacs-version "/"
+   system-configuration ")"))
+
+(defun notmuch-mua-forward-message ()
+  (message-forward)
+  (save-excursion
+(when notmuch-mua-user-agent-function
+  (let ((user-agent (funcall notmuch-mua-user-agent-function)))
+   (when (not (string= "" user-agent))
+ (message-add-header (format "User-Agent: %s" user-agent)
+(message-sort-headers)
+(message-hide-headers))
+  (set-buffer-modified-p nil))
+
+(defun notmuch-mua-mail (&optional to subject other-headers continue
+  switch-function yank-action send-actions)
+  (interactive)
+
+  (when notmuch-mua-user-agent-function
+(let ((user-agent (funcall notmuch-mua-user-agent-function)))
+  (when (not (string= "" user-agent))
+   (push (cons "User-Agent" user-agent) other-headers
+
+  (message-mail to subject other-headers continue
+   switch-function yank-action send-actions)
+  (message-hide-headers))
+
+(defun notmuch-mua-send-and-exit (&optional arg)
+  (interactive "P")
+  (message-send-and-exit arg))
+
+(defun notmuch-mua-kill-buffer ()
+  (interactive)
+  (message-kill-buffer))
+
+(defun notmuch-mua-message-send-hook ()
+  "The default function used for `notmuch-mua-send-hook', this
+simply runs the corresponding `message-mode' hook functions."
+  (run-hooks 'message-send-hook))
+
+;;
+
+(define-mail-user-agent 'notmuch-user-agent
+  'notmuch-mua-mail 'notmuch-mua-send-and-exit
+  'notmuch-mua-kill-buffer 'notmuch-mua-send-hook)
+
+;;
+
+(provide 'notmuch-mua)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 54d1c48..d1b0f1a 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -30,6 +30,7 @@
 (require 'notmuch-lib)
 (require 'notmuch-query)
 (require 'notmuch-wash)
+(require 'notmuch-mua)

 (declare-function notmuch-call-notmuch-process "notmuch" (&rest args))
 (declare-function notmuch-reply "notmuch" (query-string))
@@ -519,7 +520,7 @@ function is used. "
(define-key map (kbd "M-TAB") 'notmuch-show-previous-button)
(define-key map (kbd "TAB") 'notmuch-show-next-button)
(define-key map "s" 'notmuch-search)
-   (define-key map

[notmuch] Bulk message tagging

[Jesse Rosenthal]

On Thu, 15 Apr 2010 16:04:38 -0400, Jesse Rosenthal  
wrote:
> Not quite true: the region command only executes one "notmuch tag"
> command over "id:X or id:Y or id:Z or ...". 

Sorry -- I meant, of course: over "thread:X or thread:Y or thread:Z or ..."

added feature idea page to the wiki

[Dirk Hohndel]

I figured we should have a central place to collect feature ideas -
finding them in the mail archives (and IRC logs) is getting old...

So I started a feature idea / request page on the wiki - please comment
and add your own requests.

http://notmuchmail.org/feature-requests/

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

added feature idea page to the wiki

[Dirk Hohndel]

I figured we should have a central place to collect feature ideas -
finding them in the mail archives (and IRC logs) is getting old...

So I started a feature idea / request page on the wiki - please comment
and add your own requests.

http://notmuchmail.org/feature-requests/

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center

[notmuch] Bulk message tagging

[Jesse Rosenthal]

On Wed, 14 Apr 2010 17:59:01 -0700, Carl Worth  wrote:
> We could fix all[*] the bugs of "*" by changing it to simply call the
> new region-based tagging function. The only concern I have with that is
> that it might be significantly slower, (it will execute N "notmuch tag"
> commands to tag the N threads in the current buffer, rather than just
> one "notmuch tag" command with the same search).

Not quite true: the region command only executes one "notmuch tag"
command over "id:X or id:Y or id:Z or ...". 

It does have to iterate over the messages to get the ids, and again to
set the tags (i.e., write them in the buffer), but that's all in the
buffer -- there's only one xapian command. 

And anything that updates the buffer in real time would have to iterate
through the messages to rewrite the tag representation, so I'm not sure
if there's that much being lost here.

That being said, there might be a bit of redundancy (one save-excursion
trip through the buffer to get the tags for completion, another to get
the ids, and one more to rewrite the parenthetical tag
representation). But I'm not quite sure how to avoid that, or how
expensive it actually is.

Best,
Jesse

"bouncing" messages

[Jameson Rollins]

Does anyone know how to "bounce" a message, in the mutt sense of the
term where the message is send unaltered to a new recipient, in
notmuch/emacs?  I can't find any way to do it with message-mode.  I
think this was very useful feature in mutt, and it would be great if we
could add a command to notmuch-show to do the same thing.  Any
suggestions?

jamie.


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

Re: The archive operation should only archive open messages

[Jesse Rosenthal]

On Thu, 15 Apr 2010 13:41:17 -0700, Carl Worth  wrote:
> A bad bug occurs when paging through the thread with the space
> bar. After showing me these few messages, it will then proceed to
> archive *all* the messages in the thread (not only those it showed
> me). And I'm likely to be unaware of this since the closed (but not yet
> archived) messages are not easily distinguished from messages that were
> previously closed and archived.

This actually brings up a behavior that bites me from time to time. I
often mark messages "to-reply", and notmuch colors them red for
me. Then, when I reply to the message, it auto-removes the tag (based on
a message-mode hook I sent to the thread a while back*). I've gotten to
the point where I depend on this behavior.

However, when I have a long thread, and only one message in the inbox,
tagging the thread, of course, tags all the messages in it "to-reply."
Now, the way to do it might be to just change my habits, and only tag
while in show-mode, as opposed to search-mode. But this does seem to be
in conflict with the way I intuitively want to handle my mail, and I
imagine I'm not the only one.

Which is all just to say that I think that archiving is just a special
case of tagging/untagging, and that the issues raised here should be
considered across the larger general case.

[*] id:87pr3iygrx@jhu.edu

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

Re: The archive operation should only archive open messages

[Dirk Hohndel]

On Thu, 15 Apr 2010 13:41:17 -0700, Carl Worth  wrote:
> One of the searches that I use most frequently, (for mail that I want to
> respond to on a fairly timely basis), is
> 
>   tag:inbox and tag:to-me [*]
> 
> Sometimes, this search will show a large mailing-list thread with only a
> few messages open. Perhaps part-way through the thread, someone started
> to CC me. Or perhaps my address got dropped from the CC at some
> point. Either way, I am presented with a subset of the messages from the
> thread, even though all of the thread's messages are in my inbox still.
> 
> That much is just fine. I'm giving priority to messages where people
> thought I would be particularly interested, and that's just as it should
> be.
> 
> A bad bug occurs when paging through the thread with the space
> bar. After showing me these few messages, it will then proceed to
> archive *all* the messages in the thread (not only those it showed
> me). And I'm likely to be unaware of this since the closed (but not yet
> archived) messages are not easily distinguished from messages that were
> previously closed and archived.
> 
> Some people will claim (and I've even agreed) that the space bar is too
> magic. But this bug also happens with an explicit command to archive the
> current thread (such as hitting 'a').
> 
> I think the fix is to change these commands to only archive the messages
> that are currently open. That will make these operations behave as I
> expect, and I don't think will cause any unexpected or confusing
> behavior. But please let me know if you disagree.

I am always confused about the behavior of 'a' - does it archive the
current message? Or the current thread? Or the current thread down to
where I am? Or (as you propose) just the open messages?

I think we really need to spend some time to crsiply define the
semantics of these commands.

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

The archive operation should only archive open messages

[Dirk Hohndel]

On Thu, 15 Apr 2010 13:41:17 -0700, Carl Worth  wrote:
> One of the searches that I use most frequently, (for mail that I want to
> respond to on a fairly timely basis), is
> 
>   tag:inbox and tag:to-me [*]
> 
> Sometimes, this search will show a large mailing-list thread with only a
> few messages open. Perhaps part-way through the thread, someone started
> to CC me. Or perhaps my address got dropped from the CC at some
> point. Either way, I am presented with a subset of the messages from the
> thread, even though all of the thread's messages are in my inbox still.
> 
> That much is just fine. I'm giving priority to messages where people
> thought I would be particularly interested, and that's just as it should
> be.
> 
> A bad bug occurs when paging through the thread with the space
> bar. After showing me these few messages, it will then proceed to
> archive *all* the messages in the thread (not only those it showed
> me). And I'm likely to be unaware of this since the closed (but not yet
> archived) messages are not easily distinguished from messages that were
> previously closed and archived.
> 
> Some people will claim (and I've even agreed) that the space bar is too
> magic. But this bug also happens with an explicit command to archive the
> current thread (such as hitting 'a').
> 
> I think the fix is to change these commands to only archive the messages
> that are currently open. That will make these operations behave as I
> expect, and I don't think will cause any unexpected or confusing
> behavior. But please let me know if you disagree.

I am always confused about the behavior of 'a' - does it archive the
current message? Or the current thread? Or the current thread down to
where I am? Or (as you propose) just the open messages?

I think we really need to spend some time to crsiply define the
semantics of these commands.

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center

Re: The archive operation should only archive open messages

[Jameson Rollins]

On Thu, 15 Apr 2010 13:41:17 -0700, Carl Worth  wrote:
> Some people will claim (and I've even agreed) that the space bar is too
> magic. But this bug also happens with an explicit command to archive the
> current thread (such as hitting 'a').
>
> I think the fix is to change these commands to only archive the messages
> that are currently open. That will make these operations behave as I
> expect, and I don't think will cause any unexpected or confusing
> behavior. But please let me know if you disagree.

I actually *really* don't like that the space bar does this.  In fact, I
build my own notmuch-show-advance function in a notmuch-hacks.el that I
load to expressly get around this.  The only tag manipulation I want
done automatically is removal of "unread" when I visit a message.  Other
than that, I want to do all tag manipulation manually.  So I would be
thrilled is this "feature" was removed entirely, which would of course
get rid of this bug as well.

> [*] My tag:to-me is set by a script doing "notmuch tag +to-me
> to:cwo...@cworth.org or to:carl.d.wo...@intel.com ...". I'd prefer this
> to be a saved-search of course---that's one of the patches I haven't had
> a chance to review yet.

I've asked this in the past, but isn't this exactly what notmuch
"folders" are?  Is there a reason you don't just define this search as a
folder?

jamie.


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

The archive operation should only archive open messages

[Carl Worth]

One of the searches that I use most frequently, (for mail that I want to
respond to on a fairly timely basis), is

tag:inbox and tag:to-me [*]

Sometimes, this search will show a large mailing-list thread with only a
few messages open. Perhaps part-way through the thread, someone started
to CC me. Or perhaps my address got dropped from the CC at some
point. Either way, I am presented with a subset of the messages from the
thread, even though all of the thread's messages are in my inbox still.

That much is just fine. I'm giving priority to messages where people
thought I would be particularly interested, and that's just as it should
be.

A bad bug occurs when paging through the thread with the space
bar. After showing me these few messages, it will then proceed to
archive *all* the messages in the thread (not only those it showed
me). And I'm likely to be unaware of this since the closed (but not yet
archived) messages are not easily distinguished from messages that were
previously closed and archived.

Some people will claim (and I've even agreed) that the space bar is too
magic. But this bug also happens with an explicit command to archive the
current thread (such as hitting 'a').

I think the fix is to change these commands to only archive the messages
that are currently open. That will make these operations behave as I
expect, and I don't think will cause any unexpected or confusing
behavior. But please let me know if you disagree.

-Carl

[*] My tag:to-me is set by a script doing "notmuch tag +to-me
to:cwo...@cworth.org or to:carl.d.wo...@intel.com ...". I'd prefer this
to be a saved-search of course---that's one of the patches I haven't had
a chance to review yet.


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

The archive operation should only archive open messages

[Carl Worth]

One of the searches that I use most frequently, (for mail that I want to
respond to on a fairly timely basis), is

tag:inbox and tag:to-me [*]

Sometimes, this search will show a large mailing-list thread with only a
few messages open. Perhaps part-way through the thread, someone started
to CC me. Or perhaps my address got dropped from the CC at some
point. Either way, I am presented with a subset of the messages from the
thread, even though all of the thread's messages are in my inbox still.

That much is just fine. I'm giving priority to messages where people
thought I would be particularly interested, and that's just as it should
be.

A bad bug occurs when paging through the thread with the space
bar. After showing me these few messages, it will then proceed to
archive *all* the messages in the thread (not only those it showed
me). And I'm likely to be unaware of this since the closed (but not yet
archived) messages are not easily distinguished from messages that were
previously closed and archived.

Some people will claim (and I've even agreed) that the space bar is too
magic. But this bug also happens with an explicit command to archive the
current thread (such as hitting 'a').

I think the fix is to change these commands to only archive the messages
that are currently open. That will make these operations behave as I
expect, and I don't think will cause any unexpected or confusing
behavior. But please let me know if you disagree.

-Carl

[*] My tag:to-me is set by a script doing "notmuch tag +to-me
to:cworth at cworth.org or to:carl.d.worth at intel.com ...". I'd prefer this
to be a saved-search of course---that's one of the patches I haven't had
a chance to review yet.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100415/ce17d605/attachment.pgp>

Re: [notmuch] Bulk message tagging

[Jesse Rosenthal]

On Thu, 15 Apr 2010 16:04:38 -0400, Jesse Rosenthal  wrote:
> Not quite true: the region command only executes one "notmuch tag"
> command over "id:X or id:Y or id:Z or ...". 

Sorry -- I meant, of course: over "thread:X or thread:Y or thread:Z or ..."
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] Bulk message tagging

[Jesse Rosenthal]

On Wed, 14 Apr 2010 17:59:01 -0700, Carl Worth  wrote:
> We could fix all[*] the bugs of "*" by changing it to simply call the
> new region-based tagging function. The only concern I have with that is
> that it might be significantly slower, (it will execute N "notmuch tag"
> commands to tag the N threads in the current buffer, rather than just
> one "notmuch tag" command with the same search).

Not quite true: the region command only executes one "notmuch tag"
command over "id:X or id:Y or id:Z or ...". 

It does have to iterate over the messages to get the ids, and again to
set the tags (i.e., write them in the buffer), but that's all in the
buffer -- there's only one xapian command. 

And anything that updates the buffer in real time would have to iterate
through the messages to rewrite the tag representation, so I'm not sure
if there's that much being lost here.

That being said, there might be a bit of redundancy (one save-excursion
trip through the buffer to get the tags for completion, another to get
the ids, and one more to rewrite the parenthetical tag
representation). But I'm not quite sure how to avoid that, or how
expensive it actually is.

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

Re: [PATCH] First tests for JSON output and UTF-8 in mail body and subject

[Carl Worth]

On Thu, 15 Apr 2010 10:33:46 +0200, Michal Sojka  wrote:
> are you still interrested in modular test suite from git? If so, could
> you please look at id:87mxxg7bxo@steelpick.2x.cz and tell me your
> opinion. I'm still updating the modularized tests to match the state in
> master but every change in master takes me quite long time to convert.

Hi Michal,

I would still like to have a modular test suite, yes.

Thanks for pointing out that other message to me, which I had missed in
the general notmuch-mailing-list backlog I'm still dealing with. I've
now replied to it over there.

I am sorry that you keep having to re-do a bunch of work to keep your
patch up-to-date. I'm just about to push another change which might
further cause problems.

But you might actually like that change since it's one you requested in
your first version of the modular test suite. I'm dropping the annoying
execute_expecting macro that both runs notmuch and tests the
output. There's now a much cleaner separation such as:

output=$($NOTMUCH search for-something)
pass_if_equal "$output" "something was found"

I still think it wouldn't be hard to just gradually implement any
particular features we want in the test suite. But if the git thing ever
does become available, then that will be fine too.

-Carl


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

[PATCH] First tests for JSON output and UTF-8 in mail body and subject

[Carl Worth]

On Thu, 15 Apr 2010 10:33:46 +0200, Michal Sojka  wrote:
> are you still interrested in modular test suite from git? If so, could
> you please look at id:87mxxg7bxo.fsf at steelpick.2x.cz and tell me your
> opinion. I'm still updating the modularized tests to match the state in
> master but every change in master takes me quite long time to convert.

Hi Michal,

I would still like to have a modular test suite, yes.

Thanks for pointing out that other message to me, which I had missed in
the general notmuch-mailing-list backlog I'm still dealing with. I've
now replied to it over there.

I am sorry that you keep having to re-do a bunch of work to keep your
patch up-to-date. I'm just about to push another change which might
further cause problems.

But you might actually like that change since it's one you requested in
your first version of the modular test suite. I'm dropping the annoying
execute_expecting macro that both runs notmuch and tests the
output. There's now a much cleaner separation such as:

output=$($NOTMUCH search for-something)
pass_if_equal "$output" "something was found"

I still think it wouldn't be hard to just gradually implement any
particular features we want in the test suite. But if the git thing ever
does become available, then that will be fine too.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100415/75ca4410/attachment.pgp>

[PATCH] allow to not sort the search results

[Olly Betts]

Sebastian Spaeth writes:
> On 2010-04-14, Jason White wrote:
> > > Also add a --sort=unsorted command line option to notmuch search to test
> > > this.
> > 
> > Does this provide relevance-ranked search results? I think relevance ranking
> > is the Xapian default if a sort order isn't specified. 
> 
> Yes, by default it is using sort_by_relevance, so "unsorted" implies
> just that. (in fact, a previous incarnation of this patch called it
> --sort=relevance)

Except notmuch (at least in the code I've looked at) sets the weighting scheme
to BoolWeight, so the ordering is actually just the raw docid ordering
(BoolWeight gives all matching docs a weight of 0).

> I would be happy to have it called --sort=relevance too, the unsorted
> points out potential performance improvements a bit better, IMHO
> (although they seem to be really small with a warm cache).

When using the results of a search to add/remove tags, there's likely to be
an additional win from --sort=unsorted as documents will now be processed
in docid order which will tend to have a more cache friendly locality of
access.

Also, sorting by relevance requires more calculations and may require fetching
additional data (document length for example).

So I think it would make sense for --sort=relevance and --sort=unsorted to be
separate options.

Cheers,
Olly

Re: [PATCH] RFC: User-Agent header

[Carl Worth]

On Wed, 14 Apr 2010 09:44:16 +0200, "Sebastian Spaeth"  
wrote:
> On 2010-04-13, Carl Worth wrote:
> > No, wait! I want more from you. :-)
> 
> Sigh, they always want more :-)

Sorry about that. :-)

> See the "sister mail" to this thread, in which I simply added the whole
> shebang to notmuch.el (not using a lambda function). Is that what you
> had in mind.

Yes, that looks pretty good. But David has some improvements in mind,
this feature was implemented after the 0.2 merge window closed, *and*
I've committed to David to not keep messing with the emacs code before
merging in his outstanding changes.

So I'm going to wait on this for now at least.

> Is that "version" really needed, BTW? Why can't notmuch --version not just 
> say:
> notmuch 0.1-107-g553feae

Good point. I think I was imitating the "git --version" output or
something. I can't give any reason for this though. I'll fix this.

-Carl


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

[PATCH] RFC: User-Agent header

[Carl Worth]

On Wed, 14 Apr 2010 09:44:16 +0200, "Sebastian Spaeth"  wrote:
> On 2010-04-13, Carl Worth wrote:
> > No, wait! I want more from you. :-)
> 
> Sigh, they always want more :-)

Sorry about that. :-)

> See the "sister mail" to this thread, in which I simply added the whole
> shebang to notmuch.el (not using a lambda function). Is that what you
> had in mind.

Yes, that looks pretty good. But David has some improvements in mind,
this feature was implemented after the 0.2 merge window closed, *and*
I've committed to David to not keep messing with the emacs code before
merging in his outstanding changes.

So I'm going to wait on this for now at least.

> Is that "version" really needed, BTW? Why can't notmuch --version not just 
> say:
> notmuch 0.1-107-g553feae

Good point. I think I was imitating the "git --version" output or
something. I can't give any reason for this though. I'll fix this.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100415/3eacf251/attachment.pgp>

[PATCH] configure: Fix syntax error (spaces in assignment).

[Gregor Hoffleit]

Before and after the assignment operator, no spaces are allowed.
I don't know if there are any /bin/sh which allow spaces, but at least
in bash, csh and zsh, the former code was no valid assigment.
---
 configure |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index eebe075..7f5ca7d 100755
--- a/configure
+++ b/configure
@@ -238,11 +238,11 @@ printf "Checking for Mac OS X (for shared library)... "
 if [ `uname` = "Darwin" ] ; then
 printf "Yes.\n"
 mac_os_x=1
-linker_resolves_library_dependencies = 0
+linker_resolves_library_dependencies=0
 else
 printf "No.\n"
 mac_os_x=0
-linker_resolves_library_dependencies = 1
+linker_resolves_library_dependencies=1
 fi

 if [ $errors -gt 0 ]; then
-- 
1.7.0.4

Re: [PATCH] test-lib.sh: Add explicit license detail, with change from GPLv2 to GPLv2+.

[Carl Worth]

On Tue, 06 Apr 2010 19:01:07 +0200, Michal Sojka  wrote:
> here is my report of git's test-lib relicensing. The following is the
> last list sent to me by Junio. I guess you have this information
> somewhere in your mailbox as well.

Hi Michal,

Thanks for following up with this.

> There are three contributors who didn't respond to me. The contributions
> of two of them are clearly not copyrightable (Stephan Beyer and Bert
> Wesarg - see the links to commits in the wiki). The last contributor is
> Bryan Donlan who fix a few quoting problems which are quite simple but I
> do not have any clue whether this is copyrightable or not
> (see gitk --author='Bryan Donlan' t/test-lib.sh).
> 
> Junio was talking about only three missing Acks so I guess he already
> did some filtering based on copyrightability. Do you know which three
> Acks were missing according to Junio and whether these are in my list?

It seems you've done a careful job and I appreciate that. I don't know
any more details about what Junio was expecting. And he's really the one
you should approach at this point.

I do not plan to accept this source into our tree until the git project
itself has accepted the license change on its own. So if the above
analysis satisfies Junio, and he accepts the patch, then we can take it.

-Carl


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

[PATCH] test-lib.sh: Add explicit license detail, with change from GPLv2 to GPLv2+.

[Carl Worth]

On Tue, 06 Apr 2010 19:01:07 +0200, Michal Sojka  wrote:
> here is my report of git's test-lib relicensing. The following is the
> last list sent to me by Junio. I guess you have this information
> somewhere in your mailbox as well.

Hi Michal,

Thanks for following up with this.

> There are three contributors who didn't respond to me. The contributions
> of two of them are clearly not copyrightable (Stephan Beyer and Bert
> Wesarg - see the links to commits in the wiki). The last contributor is
> Bryan Donlan who fix a few quoting problems which are quite simple but I
> do not have any clue whether this is copyrightable or not
> (see gitk --author='Bryan Donlan' t/test-lib.sh).
> 
> Junio was talking about only three missing Acks so I guess he already
> did some filtering based on copyrightability. Do you know which three
> Acks were missing according to Junio and whether these are in my list?

It seems you've done a careful job and I appreciate that. I don't know
any more details about what Junio was expecting. And he's really the one
you should approach at this point.

I do not plan to accept this source into our tree until the git project
itself has accepted the license change on its own. So if the above
analysis satisfies Junio, and he accepts the patch, then we can take it.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100415/6439b50d/attachment.pgp>

[PATCH] Try to provide search buffers with titles from notmuch-folders.

[David Bremner]

On Thu, 15 Apr 2010 08:16:09 -0400, Servilio Afre Puentes  wrote:
> ---
>  emacs/notmuch.el |   11 ++-
>  1 files changed, 10 insertions(+), 1 deletions(-)
> 

Thanks very much for the contribution. It would be nice (and Carl will
almost certainly ask for this) to have a meaningful commit message.

All the best

David

[PATCH] First tests for JSON output and UTF-8 in mail body and subject

[Michal Sojka]

On Thu, 15 Apr 2010, Carl Worth wrote:
> On Tue, 13 Apr 2010 18:37:57 +0200, Gregor Hoffleit  
> wrote:
> > The test suite doesn't yet cover --format=json output nor UTF-8 in
> > subject or body.
> > 
> > This patch starts with test cases for 'search --format=json' and
> > 'show --format=json'.
> 
> Thanks for the tests, Gregor!

Carl,

are you still interrested in modular test suite from git? If so, could
you please look at id:87mxxg7bxo.fsf at steelpick.2x.cz and tell me your
opinion. I'm still updating the modularized tests to match the state in
master but every change in master takes me quite long time to convert.

-Michal

Re: [PATCH] emacs: Re-arrange message sending code

[David Edmondson]

On Thu, 15 Apr 2010 16:50:27 +0100, David Edmondson  wrote:
> Define a new `mail-user-agent' (`notmuch-user-agent') and use it by
> default. Re-arrange various routines that send mail to use this
> (compose, reply, forward). Insert a `User-Agent:' header by default.

I meant to add that this was a proposal in response to Sebastian's
User-Agent related patch (id:87y6gtnkch@sspaeth.de).

Setting `mail-user-agent' in notmuch.el is a bit aggressive, but without
requiring some configuration on the part of the user (which Carl
appeared to want to avoid) it's not obvious how to make things as
simple as the existing approach.

dme.
-- 
David Edmondson, http://dme.org
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] emacs: Re-arrange message sending code

[David Edmondson]

Define a new `mail-user-agent' (`notmuch-user-agent') and use it by
default. Re-arrange various routines that send mail to use this
(compose, reply, forward). Insert a `User-Agent:' header by default.
---
 emacs/notmuch-hello.el |2 +
 emacs/notmuch-mua.el   |   94 
 emacs/notmuch-show.el  |5 ++-
 emacs/notmuch.el   |   43 --
 4 files changed, 130 insertions(+), 14 deletions(-)
 create mode 100644 emacs/notmuch-mua.el

diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index c49a35f..83586f2 100644
--- a/emacs/notmuch-hello.el
+++ b/emacs/notmuch-hello.el
@@ -25,6 +25,7 @@
 
 (require 'notmuch-lib)
 (require 'notmuch)
+(require 'notmuch-mua)
 
 (declare-function notmuch-search "notmuch" (query &optional oldest-first 
target-thread target-line))
 (declare-function notmuch-folder-count "notmuch" (search))
@@ -314,6 +315,7 @@ diagonal."
 
   (use-local-map widget-keymap)
   (local-set-key "=" 'notmuch-hello-update)
+  (local-set-key "m" 'notmuch-mua-mail)
   (local-set-key "q" '(lambda () (interactive) (kill-buffer (current-buffer
   (local-set-key "s" 'notmuch-hello-goto-search)
 
diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
new file mode 100644
index 000..c8a8743
--- /dev/null
+++ b/emacs/notmuch-mua.el
@@ -0,0 +1,94 @@
+;; notmuch-mua.el --- emacs style mail-user-agent
+;;
+;; Copyright © David Edmondson
+;;
+;; This file is part of Notmuch.
+;;
+;; Notmuch is free software: you can redistribute it and/or modify it
+;; under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+;;
+;; Notmuch is distributed in the hope that it will be useful, but
+;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+;; General Public License for more details.
+;;
+;; You should have received a copy of the GNU General Public License
+;; along with Notmuch.  If not, see .
+;;
+;; Authors: David Edmondson 
+
+(require 'message)
+
+;;
+
+(defcustom notmuch-mua-send-hook '(notmuch-mua-message-send-hook)
+  "Hook run before sending messages."
+  :group 'notmuch
+  :type 'hook)
+
+(defcustom notmuch-mua-user-agent-function 'notmuch-mua-user-agent
+  "Function used to generate a `User-Agent:' string. If this is
+`nil' then no `User-Agent:' will be generated."
+  :group 'notmuch
+  :type 'function)
+
+;;
+
+(defun notmuch-mua-user-agent ()
+  "Generate a `User-Agent:' string suitable for notmuch."
+  (concat
+   ;; Trim off the trailing newline.
+   (substring (shell-command-to-string
+  (concat notmuch-command " --version"))
+ 0 -1)
+   " (Emacs " emacs-version "/"
+   system-configuration ")"))
+
+(defun notmuch-mua-forward-message ()
+  (message-forward)
+  (save-excursion
+(when notmuch-mua-user-agent-function
+  (let ((user-agent (funcall notmuch-mua-user-agent-function)))
+   (when (not (string= "" user-agent))
+ (message-add-header (format "User-Agent: %s" user-agent)
+(message-sort-headers)
+(message-hide-headers))
+  (set-buffer-modified-p nil))
+
+(defun notmuch-mua-mail (&optional to subject other-headers continue
+  switch-function yank-action send-actions)
+  (interactive)
+
+  (when notmuch-mua-user-agent-function
+(let ((user-agent (funcall notmuch-mua-user-agent-function)))
+  (when (not (string= "" user-agent))
+   (push (cons "User-Agent" user-agent) other-headers
+
+  (message-mail to subject other-headers continue
+   switch-function yank-action send-actions)
+  (message-hide-headers))
+
+(defun notmuch-mua-send-and-exit (&optional arg)
+  (interactive "P")
+  (message-send-and-exit arg))
+
+(defun notmuch-mua-kill-buffer ()
+  (interactive)
+  (message-kill-buffer))
+
+(defun notmuch-mua-message-send-hook ()
+  "The default function used for `notmuch-mua-send-hook', this
+simply runs the corresponding `message-mode' hook functions."
+  (run-hooks 'message-send-hook))
+
+;;
+
+(define-mail-user-agent 'notmuch-user-agent
+  'notmuch-mua-mail 'notmuch-mua-send-and-exit
+  'notmuch-mua-kill-buffer 'notmuch-mua-send-hook)
+
+;;
+
+(provide 'notmuch-mua)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 54d1c48..d1b0f1a 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -30,6 +30,7 @@
 (require 'notmuch-lib)
 (require 'notmuch-query)
 (require 'notmuch-wash)
+(require 'notmuch-mua)
 
 (declare-function notmuch-call-notmuch-process "notmuch" (&rest args))
 (declare-function notmuch-reply "notmuch" (query-string))
@@ -519,7 +520,7 @@ function is used. "
(define-key map (kbd "M-TAB") 'notmuch-show-previous-button)
(define-key map (kbd "TAB") 'notmuch-show-next-button)
(define-key map "s" 'notmuch-search)
-   (define-ke

[PATCH] Try to provide search buffers with titles from notmuch-folders.

[Servilio Afre Puentes]

---
 emacs/notmuch.el |   11 ++-
 1 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index be09f42..17e0e86 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -696,6 +696,15 @@ characters as well as `_.+-'.
 (apply 'notmuch-call-notmuch-process "tag"
   (append action-split (list notmuch-search-query-string) nil

+(defun notmuch-search-buffer-title (query)
+  "Returns the title for a buffer with notmuch search results."
+  (let ((folder (car (rassoc query notmuch-folders
+   (if folder
+  (concat "*notmuch-folder-" folder "*")
+(concat "*notmuch-search-" query "*"))
+   )
+)
+
 ;;;###autoload
 (defun notmuch-search (query &optional oldest-first target-thread target-line)
   "Run \"notmuch search\" with the given query string and display results.
@@ -708,7 +717,7 @@ The optional parameters are used as follows:
   target-line: The line number to move to if the target thread does not
appear in the search results."
   (interactive "sNotmuch search: ")
-  (let ((buffer (get-buffer-create (concat "*notmuch-search-" query "*"
+  (let ((buffer (get-buffer-create (notmuch-search-buffer-title query
 (switch-to-buffer buffer)
 (notmuch-search-mode)
 (set 'notmuch-search-query-string query)
-- 
1.7.0.4

Re: [PATCH] Try to provide search buffers with titles from notmuch-folders.

[David Bremner]

On Thu, 15 Apr 2010 08:16:09 -0400, Servilio Afre Puentes  
wrote:
> ---
>  emacs/notmuch.el |   11 ++-
>  1 files changed, 10 insertions(+), 1 deletions(-)
> 

Thanks very much for the contribution. It would be nice (and Carl will
almost certainly ask for this) to have a meaningful commit message.

All the best

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

Re: [PATCH] allow to not sort the search results

[Olly Betts]

Sebastian Spaeth writes:
> On 2010-04-14, Jason White wrote:
> > > Also add a --sort=unsorted command line option to notmuch search to test
> > > this.
> > 
> > Does this provide relevance-ranked search results? I think relevance ranking
> > is the Xapian default if a sort order isn't specified. 
> 
> Yes, by default it is using sort_by_relevance, so "unsorted" implies
> just that. (in fact, a previous incarnation of this patch called it
> --sort=relevance)

Except notmuch (at least in the code I've looked at) sets the weighting scheme
to BoolWeight, so the ordering is actually just the raw docid ordering
(BoolWeight gives all matching docs a weight of 0).

> I would be happy to have it called --sort=relevance too, the unsorted
> points out potential performance improvements a bit better, IMHO
> (although they seem to be really small with a warm cache).

When using the results of a search to add/remove tags, there's likely to be
an additional win from --sort=unsorted as documents will now be processed
in docid order which will tend to have a more cache friendly locality of
access.

Also, sorting by relevance requires more calculations and may require fetching
additional data (document length for example).

So I think it would make sense for --sort=relevance and --sort=unsorted to be
separate options.

Cheers,
Olly

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

[PATCH] Try to provide search buffers with titles from notmuch-folders.

[Servilio Afre Puentes]

---
 emacs/notmuch.el |   11 ++-
 1 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index be09f42..17e0e86 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -696,6 +696,15 @@ characters as well as `_.+-'.
 (apply 'notmuch-call-notmuch-process "tag"
   (append action-split (list notmuch-search-query-string) nil

+(defun notmuch-search-buffer-title (query)
+  "Returns the title for a buffer with notmuch search results."
+  (let ((folder (car (rassoc query notmuch-folders
+   (if folder
+  (concat "*notmuch-folder-" folder "*")
+(concat "*notmuch-search-" query "*"))
+   )
+)
+
 ;;;###autoload
 (defun notmuch-search (query &optional oldest-first target-thread target-line)
   "Run \"notmuch search\" with the given query string and display results.
@@ -708,7 +717,7 @@ The optional parameters are used as follows:
   target-line: The line number to move to if the target thread does not
appear in the search results."
   (interactive "sNotmuch search: ")
-  (let ((buffer (get-buffer-create (concat "*notmuch-search-" query "*"
+  (let ((buffer (get-buffer-create (notmuch-search-buffer-title query
 (switch-to-buffer buffer)
 (notmuch-search-mode)
 (set 'notmuch-search-query-string query)
-- 
1.7.0.4
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] configure: Fix syntax error (spaces in assignment).

[Gregor Hoffleit]

Before and after the assignment operator, no spaces are allowed.
I don't know if there are any /bin/sh which allow spaces, but at least
in bash, csh and zsh, the former code was no valid assigment.
---
 configure |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index eebe075..7f5ca7d 100755
--- a/configure
+++ b/configure
@@ -238,11 +238,11 @@ printf "Checking for Mac OS X (for shared library)... "
 if [ `uname` = "Darwin" ] ; then
 printf "Yes.\n"
 mac_os_x=1
-linker_resolves_library_dependencies = 0
+linker_resolves_library_dependencies=0
 else
 printf "No.\n"
 mac_os_x=0
-linker_resolves_library_dependencies = 1
+linker_resolves_library_dependencies=1
 fi
 
 if [ $errors -gt 0 ]; then
-- 
1.7.0.4
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] First tests for JSON output and UTF-8 in mail body and subject

[Michal Sojka]

On Thu, 15 Apr 2010, Carl Worth wrote:
> On Tue, 13 Apr 2010 18:37:57 +0200, Gregor Hoffleit  
> wrote:
> > The test suite doesn't yet cover --format=json output nor UTF-8 in
> > subject or body.
> > 
> > This patch starts with test cases for 'search --format=json' and
> > 'show --format=json'.
> 
> Thanks for the tests, Gregor!

Carl,

are you still interrested in modular test suite from git? If so, could
you please look at id:87mxxg7bxo@steelpick.2x.cz and tell me your
opinion. I'm still updating the modularized tests to match the state in
master but every change in master takes me quite long time to convert.

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