[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

[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

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 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 sebast...@sspaeth.de
---
 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 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 sebast...@sspaeth.de
---
 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] notmuch.c: Shorten version string

[Sebastian Spaeth]

We previously output notmuch version 0.1 as response to notmuch --version.
Shorten this to notmuch 0.1 as we know that we will receive a version
number when we explicitely ask for it.

Signed-off-by: Sebastian Spaeth sebast...@sspaeth.de
---
 notmuch.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/notmuch.c b/notmuch.c
index dcfda32..0eea5e1 100644
--- a/notmuch.c
+++ b/notmuch.c
@@ -474,7 +474,7 @@ main (int argc, char *argv[])
return notmuch_help_command (NULL, 0, NULL);
 
 if (STRNCMP_LITERAL (argv[1], --version) == 0) {
-   printf (notmuch version  STRINGIFY(NOTMUCH_VERSION) \n);
+   printf (notmuch  STRINGIFY(NOTMUCH_VERSION) \n);
return 0;
 }
 
-- 
1.7.0.4

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

notmuchsync --move (was: add a number of new feature ideas to TODO file)

[Sebastian Spaeth]

On 2010-04-16, Dirk Hohndel wrote:
 +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
 +

You can remove that bit from the patch, it is implemented now :-)

notmuchsync --move querystring targetfolder
(use with --dry-run and -d to preview changes)

once folder: search is implemented you can e.g. simply do:

notmuchsync --move not tag:inbox and folder:inbox
/home/spaetz/mail/archive/cur

and make your IMAP web clients (or iphones) happy.

This works right now already:

notmuchsync --move not tag:inbox /home/spaetz/mail/archive/cur

but is of course slower (still ok)  as it has to traverse through most
of your mails.

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

[PATCH] emacs: when archiving move the cursor depending on the sort order.

[Sebastian Spaeth]

On 2010-04-14, Michal Sojka wrote:
> On Tue, 13 Apr 2010, Servilio Afre Puentes wrote:
> > The current hardcoded behaviour will not take you to the next unread
> > thread when the sort order is set to newer-first from the default of
> > older-first.
> 
> Is this really what we want? If I sort messages by newest first, it
> menas that I want to process my emails from the newest to the oldest.
> I'm satisfied with the current behavour.

Agreed, I would be very surprised to get a different behavior.

[PATCH 13/13] notmuch.el: Add a function to insert a notmuch user-agent header

[Sebastian Spaeth]

On 2010-04-14, David Edmondson wrote:
> This really should be done with `define-mail-user-agent' and associated
> paraphernalia.

Which might be correct but beyond what I can provide :). 

So, either we take this and get a followup patch, or someone improves
it, or we drop it.

Sebastian

[PATCH] allow to not sort the search results

[Sebastian Spaeth]

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)

However, given that many of our terms, are boolean, relevance only
really comes into play when including terms within the body of a
message. (and *I* have not found the relevance sorting to be much useful
yet when I cared about some sort order, but that might just be me).

> It would be useful to be able to obtain a relevance-ranked list of messages or
> threads that satisfy a query.

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

Sebastian

[PATCH] RFC: User-Agent header

[Sebastian Spaeth]

On 2010-04-13, Carl Worth wrote:
> > OK, final post from me on this issue.
> No, wait! I want more from you. :-)

Sigh, they always want more :-)

> Would you care to put together a solution that does this from within
> notmuch*.el ? I really want things usable by default without people
> having to hack up their .emacs files.

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. Mind you, my elisp knowledge borders close to 0, so I would
be surprised if I did not botch up things. However, I have tested the
patch, and the User-Agent header got inserted.

> Of course, we could also easily add a variable to make this not happen,
> (but that can be added in a follow-on patch by anyone).

Some don't want it, but it cannot be disabled in this patch, so that
would indeed need to be a followup patch.

This gets now inserted (message mode automatically wrapped the header
like this):
User-Agent: notmuch version 0.1-107-g553feae (Emacs
23.1.1/x86_64-pc-linux-gnu)

Is that an acceptable format? I would have preferred to not include the
"version" string, but notmuch --version spits that out, and it was just
easier to leave it in. 

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

Sebastian

[PATCH 13/13] notmuch.el: Add a function to insert a notmuch user-agent header

[Sebastian Spaeth]

This adds a function (and a hook) to have notmuch insert a User-Agent header
into composed mails (even if invoked from not-notmuch ways, such as with
ctrl-x m. This is invariably added for now without the possibility to
turn it off, a task left as a homework for others.

Signed-off-by: Sebastian Spaeth 
---
 emacs/notmuch.el |   24 
 1 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 517c53a..8a7df15 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -54,6 +54,30 @@
 (require 'notmuch-lib)
 (require 'notmuch-show)

+(defun notmuch-set-user-agent-header ()
+  "Sets variables so that  message mode inserts a notmuch User-Agent 
+   header into send mails"
+  ;; check if User-Agent is a 'required' mail header and set it if not
+  (if (not (memq 'User-Agent message-required-mail-headers))
+  (setq message-required-mail-headers 
+(append message-required-mail-headers '(User-Agent
+  ;; hide the User-Agent header when composing a mail
+  (if (not (memq '"^User-Agent:" message-hidden-headers))
+  (setq message-hidden-headers 
+(append message-hidden-headers '("^User-Agent:"
+  ;; create the notmuch user agent string
+  (let ((notmuch-user-agent (concat 
+ (substring (shell-command-to-string 
+ (concat notmuch-command 
+ " --version")) 0 -1)
+ " (Emacs " emacs-version "/"
+ system-configuration ")")))
+(setq message-newsreader notmuch-user-agent)))
+
+;; set the User-Agent string whenever we invoke message mode
+;; TODO: use a variable that allows disabling.
+(add-hook 'message-mode-hook 'notmuch-set-user-agent-header)
+
 (defun notmuch-select-tag-with-completion (prompt  search-terms)
   (let ((tag-list
 (with-output-to-string
-- 
1.6.3.3

[PATCH] allow to not sort the search results

[Sebastian Spaeth]

previously we were always sorting the returned results by some string value,
but sometimes we might just be interested in the number of results, and don't
need any sorting.

Also add a --sort=unsorted command line option to notmuch search to test this.
A search that matches 1200 messages, returns in default sort in 0.982 seconds
and unsorted in 0.978 seconds with very little variance (with a warm cache).
Xapian contributor Olly Betts says that the speed gains for a cold cache are
likely to be much higher though.

Signed-off-by: Sebastian Spaeth 
---
 lib/notmuch.h|3 ++-
 lib/query.cc |2 ++
 notmuch-search.c |2 ++
 3 files changed, 6 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
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;
-- 
1.6.3.3

[PATCH] allow to not sort the search results

[Sebastian Spaeth]

previously we were always sorting the returned results by some string value,
but sometimes we might just be interested in the number of results, and don't
need any sorting.

Also add a --sort=unsorted command line option to notmuch search to test this.
A search that matches 1200 messages, returns in default sort in 0.982 seconds
and unsorted in 0.978 seconds with very little variance (with a warm cache).
Xapian contributor Olly Betts says that the speed gains for a cold cache are
likely to be much higher though.

Signed-off-by: Sebastian Spaeth sebast...@sspaeth.de
---
 lib/notmuch.h|3 ++-
 lib/query.cc |2 ++
 notmuch-search.c |2 ++
 3 files changed, 6 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
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;
-- 
1.6.3.3

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

[PATCH 13/13] notmuch.el: Add a function to insert a notmuch user-agent header

[Sebastian Spaeth]

This adds a function (and a hook) to have notmuch insert a User-Agent header
into composed mails (even if invoked from not-notmuch ways, such as with
ctrl-x m. This is invariably added for now without the possibility to
turn it off, a task left as a homework for others.

Signed-off-by: Sebastian Spaeth sebast...@sspaeth.de
---
 emacs/notmuch.el |   24 
 1 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 517c53a..8a7df15 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -54,6 +54,30 @@
 (require 'notmuch-lib)
 (require 'notmuch-show)
 
+(defun notmuch-set-user-agent-header ()
+  Sets variables so that  message mode inserts a notmuch User-Agent 
+   header into send mails
+  ;; check if User-Agent is a 'required' mail header and set it if not
+  (if (not (memq 'User-Agent message-required-mail-headers))
+  (setq message-required-mail-headers 
+(append message-required-mail-headers '(User-Agent
+  ;; hide the User-Agent header when composing a mail
+  (if (not (memq '^User-Agent: message-hidden-headers))
+  (setq message-hidden-headers 
+(append message-hidden-headers '(^User-Agent:
+  ;; create the notmuch user agent string
+  (let ((notmuch-user-agent (concat 
+ (substring (shell-command-to-string 
+ (concat notmuch-command 
+  --version)) 0 -1)
+  (Emacs  emacs-version /
+ system-configuration 
+(setq message-newsreader notmuch-user-agent)))
+
+;; set the User-Agent string whenever we invoke message mode
+;; TODO: use a variable that allows disabling.
+(add-hook 'message-mode-hook 'notmuch-set-user-agent-header)
+
 (defun notmuch-select-tag-with-completion (prompt rest search-terms)
   (let ((tag-list
 (with-output-to-string
-- 
1.6.3.3

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

However, given that many of our terms, are boolean, relevance only
really comes into play when including terms within the body of a
message. (and *I* have not found the relevance sorting to be much useful
yet when I cared about some sort order, but that might just be me).
 
 It would be useful to be able to obtain a relevance-ranked list of messages or
 threads that satisfy a query.

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

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

Re: [PATCH 13/13] notmuch.el: Add a function to insert a notmuch user-agent header

[Sebastian Spaeth]

On 2010-04-14, David Edmondson wrote:
 This really should be done with `define-mail-user-agent' and associated
 paraphernalia.

Which might be correct but beyond what I can provide :). 

So, either we take this and get a followup patch, or someone improves
it, or we drop it.

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

please eat my data!

[Sebastian Spaeth]

On 2010-04-12, Jameson Rollins wrote:
> On Mon, 12 Apr 2010 15:33:35 +0200, "Sebastian Spaeth" > Wow, this is really 
> interesting, Sebastian.  For those of us not in the
> know, can you explain what libeatmydata is and how it's used?

Hehe, I just got the pointer to it on IRC myself:

http://www.flamingspork.com/projects/libeatmydata/

You download and untar the thing, and "make" it, which produces
libeatmydata.so. Running a binary foo with LD_PRELOAD=./libeatmydata.so foo
will then effectively make all fsyncs a Noop. Not something you want on
your production systems, but great to test how much of a penality those
fsyncs really are.

What I find intersting is that we have a 2x speedup and a 10x speedup
for different queries. Olly was saying on IRC that both *should* really be
behaving in much the same manner.

Sebastian

please eat my data!

[Sebastian Spaeth]

fsync is really killing xapian (and notmuch). What suffers, are the
boolean prefixes (tag, id, and thread). Using libeatmydata (which
disables fsync) shows a 10x speedup for tagging. The speedup is only
factor 2 for e.g. from: searches. This is ext4 on recent stock
Ubuntu. Given that search by tag and thread are performed really often
(each time I advance a thread, for example), that really hurts.

With a warm file cache and a thread containing 11 messages:

---
time notmuch tag +test -- thread:0f4e
real0m0.677s
user0m0.030s
sys 0m0.020s
---
time LD_PRELOAD=./libeatmydata.so notmuch tag +test -- thread:0f4e

real0m0.040s
user0m0.020s
sys 0m0.020s
---

However tagging ~850 messages based on a from search is "ONLY" factor 2:
--
time notmuch tag +test -- from:"sebastian at sspaeth.de"

real0m2.355s
user0m1.240s
sys 0m0.040s
---
time LD_PRELOAD=./libeatmydata.so notmuch tag +test -- from:"sebastian at 
sspaeth.de"

real0m1.286s
user0m1.230s
sys 0m0.010s
---

sup-like label listings (elisp)

[Sebastian Spaeth]

On Mon, 12 Apr 2010 09:14:27 +0100, David Edmondson  wrote:
> How about this approach:

ooh! me likey!

Thanks, very nice to get an overview over all my tags.

[PATCH] RFC: User-Agent header

[Sebastian Spaeth]

OK, final post from me on this issue. This is what I am using in my
.emacs now. It does not clutter up the message compose window with a
User-Agent header as it is hidden by message mode. It is also not shown
by default in the notmuch-show modes but viewing the full headers
confirms that it is indeed being send. It works for "c-x m" and "m" in
notmuch-show mode, AND it also work for "r"eplies in notmuch-show mode.

I put this in the message mode hook because we will then not call the
notmuch binary each time we start up emacs, but it will be dynamically
be created when message mode is invoked. Not sure if others have a
cleverer solution here.

;; set the User-Agent string whenever we invoke message mode
(add-hook 'message-mode-hook '(lambda()
;; check if User-Agent is a required header and set it if not
(if (not (memq 'User-Agent message-required-mail-headers))
(setq message-required-mail-headers 
  (append message-required-mail-headers '(User-Agent
;; hide the User-Agent header if not already hidden
(if (not (memq '"^User-Agent:" message-hidden-headers))
(setq message-hidden-headers 
  (append message-hidden-headers '("^User-Agent:"
;; create user agent string
(let ((notmuch-user-agent (concat 
   (substring (shell-command-to-string (concat 
notmuch-command " --version")) 0 -1)
   " (Emacs " emacs-version "/"
system-configuration ")")))
  (setq message-newsreader notmuch-user-agent))
))

Sebastian

[PATCH] notmuch new --new-tags=tags...

[Sebastian Spaeth]

On 2010-04-10, Anthony Towns wrote:
> Hi *,
> 
> The attached patch makes "notmuch new --new-tags=unread,new" set the
> "unread" and "new" tags on any new mail it finds rather than "unread"
> and "inbox". Or whatever other tags you happen to specify.

Thanks for the patch. I can't comment on the code quality, but rather
than having to specify the set of new tags on the command line every
time, I think it would make more sense to put them in the notmuch config
file as this patch does:
id:1268432006-24333-2-git-send-email-bgamari.foss at gmail.com

Looking forward to configurable notmuch tags.

Sebastian

RFC: User-Agent header

[Sebastian Spaeth]

After some research, this is what I found/propose:

With some simple elisp am I using this User-Agent header now:

  User-Agent: notmuch version 0.1 (Emacs 23.1.1/i486-pc-linux-gnu)

This needs to be done:

1) Add "User-Agent" to the variable "message-required-headers" (it is
(optional . User-Agent) by default in message-mode.

2) Message mode will then insert a User-Agent header and fill it with
the (local) variable "message-newsreader". This is how I set my
message-newsreader now (leading to above string): 

(setq message-newsreader (concat (substring (shell-command-to-string (concat 
notmuch-command " --version")) 0 -1) " (Emacs " emacs-version "/" 
system-configuration ")"))

This works fine for composing mails with both "m" (from within notmuch)
and "c-x m" from outside notmuch. It won't work with "r" as message mode
does not seem to be involved in setting up the headers at all then. (So
notmuch-reply.c might just want to also set up the User-Agent header by
default).

sebastian

Re: [PATCH] RFC: User-Agent header

[Sebastian Spaeth]

OK, final post from me on this issue. This is what I am using in my
.emacs now. It does not clutter up the message compose window with a
User-Agent header as it is hidden by message mode. It is also not shown
by default in the notmuch-show modes but viewing the full headers
confirms that it is indeed being send. It works for c-x m and m in
notmuch-show mode, AND it also work for replies in notmuch-show mode.

I put this in the message mode hook because we will then not call the
notmuch binary each time we start up emacs, but it will be dynamically
be created when message mode is invoked. Not sure if others have a
cleverer solution here.

;; set the User-Agent string whenever we invoke message mode
(add-hook 'message-mode-hook '(lambda()
;; check if User-Agent is a required header and set it if not
(if (not (memq 'User-Agent message-required-mail-headers))
(setq message-required-mail-headers 
  (append message-required-mail-headers '(User-Agent
;; hide the User-Agent header if not already hidden
(if (not (memq '^User-Agent: message-hidden-headers))
(setq message-hidden-headers 
  (append message-hidden-headers '(^User-Agent:
;; create user agent string
(let ((notmuch-user-agent (concat 
   (substring (shell-command-to-string (concat 
notmuch-command  --version)) 0 -1)
(Emacs  emacs-version /
system-configuration 
  (setq message-newsreader notmuch-user-agent))
))

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

Re: sup-like label listings (elisp)

[Sebastian Spaeth]

On Mon, 12 Apr 2010 09:14:27 +0100, David Edmondson d...@dme.org wrote:
 How about this approach:

ooh! me likey!

Thanks, very nice to get an overview over all my tags.

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

please eat my data!

[Sebastian Spaeth]

fsync is really killing xapian (and notmuch). What suffers, are the
boolean prefixes (tag, id, and thread). Using libeatmydata (which
disables fsync) shows a 10x speedup for tagging. The speedup is only
factor 2 for e.g. from: searches. This is ext4 on recent stock
Ubuntu. Given that search by tag and thread are performed really often
(each time I advance a thread, for example), that really hurts.

With a warm file cache and a thread containing 11 messages:

---
time notmuch tag +test -- thread:0f4e
real0m0.677s
user0m0.030s
sys 0m0.020s
---
time LD_PRELOAD=./libeatmydata.so notmuch tag +test -- thread:0f4e

real0m0.040s
user0m0.020s
sys 0m0.020s
---

However tagging ~850 messages based on a from search is ONLY factor 2:
--
time notmuch tag +test -- from:sebast...@sspaeth.de

real0m2.355s
user0m1.240s
sys 0m0.040s
---
time LD_PRELOAD=./libeatmydata.so notmuch tag +test -- 
from:sebast...@sspaeth.de

real0m1.286s
user0m1.230s
sys 0m0.010s
---
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: please eat my data!

[Sebastian Spaeth]

On 2010-04-12, Jameson Rollins wrote:
 On Mon, 12 Apr 2010 15:33:35 +0200, Sebastian Spaeth  Wow, this is really 
 interesting, Sebastian.  For those of us not in the
 know, can you explain what libeatmydata is and how it's used?

Hehe, I just got the pointer to it on IRC myself:

http://www.flamingspork.com/projects/libeatmydata/

You download and untar the thing, and make it, which produces
libeatmydata.so. Running a binary foo with LD_PRELOAD=./libeatmydata.so foo
will then effectively make all fsyncs a Noop. Not something you want on
your production systems, but great to test how much of a penality those
fsyncs really are.

What I find intersting is that we have a 2x speedup and a 10x speedup
for different queries. Olly was saying on IRC that both *should* really be
behaving in much the same manner.

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

Re: RFC: User-Agent header

[Sebastian Spaeth]

After some research, this is what I found/propose:

With some simple elisp am I using this User-Agent header now:

  User-Agent: notmuch version 0.1 (Emacs 23.1.1/i486-pc-linux-gnu)

This needs to be done:

1) Add User-Agent to the variable message-required-headers (it is
(optional . User-Agent) by default in message-mode.

2) Message mode will then insert a User-Agent header and fill it with
the (local) variable message-newsreader. This is how I set my
message-newsreader now (leading to above string): 

(setq message-newsreader (concat (substring (shell-command-to-string (concat 
notmuch-command  --version)) 0 -1)  (Emacs  emacs-version / 
system-configuration )))

This works fine for composing mails with both m (from within notmuch)
and c-x m from outside notmuch. It won't work with r as message mode
does not seem to be involved in setting up the headers at all then. (So
notmuch-reply.c might just want to also set up the User-Agent header by
default).

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

Initial attempt at a "merge window" for notmuch

[Sebastian Spaeth]

On 2010-04-09, Carl Worth wrote:
> 
> Here's the current list:

Having such a list is great. So now we need to get you a key-binding
that says, "take query xy results and stuff them into the wiki" (or some
pastebin like service with a fixed URL). Looking forward to 0.2.

Sebastian

(THanks to the debian pkgs I can now use notmuch on my netbook which has
not compiler installed. Very useful, thanks. Now the issue of syncing
tags is becoming more pressing for me :-) )

Plans for the 0.2 release (this week)

[Sebastian Spaeth]

On 2010-04-10, Carl n?tmuch ? Worth wrote:
> Are you all trying to show a problem here? All of the above comes
> through fine. Perhaps it's only with non-ASCII in the From line being
> replied to? Let's test that here...

I think there are 2 issues being discussed here. One is the encoding in
the subject line (which does not look pretty in compose mail, but seems
to be the standard). I did not refer to that.

What I referred to was the json output as the encode_as_json_string (or
however it is called), simply drops chars >127, leading to missing
letters in e.g. the author names etc. I could see that in the web
frontends that are making use of json already, and once (if?) emacs uses
the json output too, this will become an issue there too.

Certainly not urgent, but it looked quite weird in the web frontends.

Sebastian

[notmuch] [PATCH v2] notmuch.el: Make notmuch-show buffer name first subject, instead of thread-id

[Sebastian Spaeth]

On 2010-04-09, Jesse Rosenthal wrote:
> sporadic access. However, one question: it looks like it was V2 of the
> patch that you pushed -- was it? Unfortunately, there was a subtle bug
> that kept on popping up (when you call notmuch-show interactively, which
> rarely happens). Later in this same thread, I offered V4 (yep, there was
> a problematic V3 too) which fixes this:

I think I picked v4 for merging, however removing the comment
(supercedes v1-3) from the commit messages. I hope that was ok with you.

Sebastian

Re: Plans for the 0.2 release (this week)

[Sebastian Spaeth]

On 2010-04-10, Carl n∅tmuch 䚳 Worth wrote:
 Are you all trying to show a problem here? All of the above comes
 through fine. Perhaps it's only with non-ASCII in the From line being
 replied to? Let's test that here...

I think there are 2 issues being discussed here. One is the encoding in
the subject line (which does not look pretty in compose mail, but seems
to be the standard). I did not refer to that.

What I referred to was the json output as the encode_as_json_string (or
however it is called), simply drops chars 127, leading to missing
letters in e.g. the author names etc. I could see that in the web
frontends that are making use of json already, and once (if?) emacs uses
the json output too, this will become an issue there too.

Certainly not urgent, but it looked quite weird in the web frontends.

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

Re: Initial attempt at a merge window for notmuch

[Sebastian Spaeth]

On 2010-04-09, Carl Worth wrote:
 
 Here's the current list:

Having such a list is great. So now we need to get you a key-binding
that says, take query xy results and stuff them into the wiki (or some
pastebin like service with a fixed URL). Looking forward to 0.2.

Sebastian

(THanks to the debian pkgs I can now use notmuch on my netbook which has
not compiler installed. Very useful, thanks. Now the issue of syncing
tags is becoming more pressing for me :-) )
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: RFC: User-Agent header

[Sebastian Spaeth]

On 2010-04-10, Carl Worth wrote:
 So I propose something like:
 
   User-Agent: Notmuch/0.2 (http://notmuchmail.org) Emacs/23.1.1 (gnu/linux)

That looks good to me. So I assume the correct strategy here would be
to:

1) have notmuch reply insert a header:

User-Agent: Notmuch/0.2 (http://notmuchmail.org)

2) have notmuch-reply.el (or whatever) add a setup mail hook that
searches for an existing User-Agent header and appends  Emacs/23.1.1
(gnu/linux)  

One issue is again, such a hook would be message mode
specific, so gnus users might not appreciate that. Also when composing a
message via c-x m this would not work. So perhaps an all lisp solution?
Again, can we hijack message mode to add our own promotion header?
Or has the time come for a notmuch-message-mode that somehow inherits
from message mode? bremner said something about dynamic bindings that
would allow that.

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

[PATCH] Have notmuch count default to showing the total.

[Sebastian Spaeth]

On 2010-04-08, Mike Kelly wrote:
> If no parameters are given to notmuch-count, or just '' or '*' are
> given, return the total number of messages in the database.

I know that cworth was concerned about this syntax on IRC as that would
mean that "notmuch show" would have to spew out all your emails in order
to remain consistent with the search term (he rather wanted to output a
help text if no search term was given).

But let me express support (It's notmuch worth, I know (haha)) for this
patch. I think it makes lots of sense:

1) I often want to know how many mails are in my db. "notmuch count" or
"notmuch count *" is the intuitive syntax I would use for that. Right
now there is no way as far as I can see.

2) Search terms filter out things. The empty search term stands
therefore for all my mails. It is consistent to have the search term ''
represent all my mail.

3) I don't expect a help text for "notmuch count" just as I don't expect
a help text for "notmuch log", we are very explicit about "notmuch help"
and "notmuch help count" in many parts of our documentation.

I'm using this and find it very handy.

Sebastian

Plans for the 0.2 release (this week)

[Sebastian Spaeth]

On 2010-04-09, Michal Sojka wrote:
> "Decode headers in reply"
> (id:1267602656-24940-1-git-send-email-sojkam1 at fel.cvut.cz) is another
> patch, which is quite essential to me. Am I the only one here, who needs
> to reply to messages with non-ASCII characters?

Nope, and it looks currently very ugly. Having a good solution for that
problem would be nice indeed.

Perhaps Carl should get more N?rw?g?a? friends, :-).

spaetz

[notmuch] [Sebastian Spaeth] Pull requests

[Sebastian Spaeth]

On 2010-04-08, Michal Sojka wrote:
> I think that the patch you sent was not the latest version. The latest
> is in id:1265122868-12133-1-git-send-email-sojkam1 at fel.cvut.cz, but it
> is not rebased to the current master.

Not sure what I am doing wrong, but with this patch even after a
dump/delete/new/restore. I get

./notmuch count to:
11788
./notmuch count folder:
247
./notmuch count folder:inbox
0

My folders have no weird naming, they are e.g.:
/home/spaetz/mail/INBOX/cur/1258732076_0.22934.spaetz-macbook,U=468,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,S

Sebastian

Re: [notmuch] [Sebastian Spaeth] Pull requests

[Sebastian Spaeth]

On 2010-04-08, Michal Sojka wrote:
 I think that the patch you sent was not the latest version. The latest
 is in id:1265122868-12133-1-git-send-email-sojk...@fel.cvut.cz, but it
 is not rebased to the current master.

Not sure what I am doing wrong, but with this patch even after a
dump/delete/new/restore. I get

./notmuch count to:
11788
./notmuch count folder:
247
./notmuch count folder:inbox
0

My folders have no weird naming, they are e.g.:
/home/spaetz/mail/INBOX/cur/1258732076_0.22934.spaetz-macbook,U=468,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,S

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

RFC: User-Agent header

[Sebastian Spaeth]

notmuch is (mostly) not responsible for sending email. However, people
using the emacs frontend use notmuch to create the reply.

Am I the only one who is sometimes curious as to what mail agents others
use? Would it be useful to insert a header to notmuch reply analog to:

User-Agent: Mutt/1.5.13 (2006-08-11)

We could reuse the same version string that we use for the release (or
the git string that was used to build notmuch). I can use this to create
nice stats :).

No patch yet, just asking if this is a good idea or not.

Sebastian

[PATCH] Fix code extracting the MTA from Received: headers

[Sebastian Spaeth]

On 2010-04-07, Dirk Hohndel wrote:
> 
> The previous code made too many assumptions about the (sadly not
> standardized) format of the Received headers. This version should
> be more robust to deal with different variations.

This code might be useful for some, but I know it is not being useful
for me. I use e.g. dreamhost.com as my mail provider and I never have my
email domain name show up after the Received: by .
See my Received headers for your message below.

On the other hand, it contains "for " stating the
intended email address explicitely. IMHO, we should use this before we
start some hand-wavy guessing.

Also, I have the "X-Original-To: sebastian at sspaeth.de" header. Is that
something that we could make use of before starting to guess?

Sebastian
---
Received: from segal.dreamhost.com (mx1.spunky.mail.dreamhost.com 
[208.97.132.47])
by homiemail-mx12.g.dreamhost.com (Postfix) with ESMTP id 9A6602781BC
for ; Wed,  7 Apr 2010 13:38:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
by segal.dreamhost.com (Postfix) with ESMTP id 9CF8A5341BE
for ; Wed,  7 Apr 2010 13:38:48 -0700 (PDT)
Received: from connor.dreamhost.com ([208.97.132.81])
by localhost (segal.dreamhost.com [208.97.132.104]) (amavisd-new, port 
10024)
with ESMTP id S3IlsMcJewY1 for ;
Wed,  7 Apr 2010 13:38:39 -0700 (PDT)
Received: from olra.theworths.org (u15218177.onlinehome-server.com 
[82.165.184.25])
by connor.dreamhost.com (Postfix) with ESMTP id 33B472C9806F
for ; Wed,  7 Apr 2010 13:38:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
by olra.theworths.org (Postfix) with ESMTP id 1978741733A;
Wed,  7 Apr 2010 13:38:38 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
Received: from olra.theworths.org ([127.0.0.1])
by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id ZbcQaubefNY6; Wed,  7 Apr 2010 13:38:37 -0700 (PDT)
Received: from olra.theworths.org (localhost [127.0.0.1])
by olra.theworths.org (Postfix) with ESMTP id 044574196F4;
Wed,  7 Apr 2010 13:38:35 -0700 (PDT)

Plans for the 0.2 release (this week)

[Sebastian Spaeth]

First of all, thanks for the great work Carl. I have to admit I was
getting nervous about the backlog of patches, but your recent committing
binge (you did say your work patterns are bursty :-)) made me very happy.

That having said, I am glad to meet your expectation: "I expect people
 to remind me of their favorite features that haven't been merged..."
 :-)

>   * Any further changes from the Sebastian's repository. Sebastian, I
> worked through one list I saw recently. Do you have another list to
> propose yet?

One of the things I have seen no comment on yet, is the
"json_quote_str should handle non-ASCII characters" patch in 
id:1267697893-sup-4538 at sam.mediasupervision.de.

Right now, every char > 127 will simply be suppressed, this patch fixes
this for me but I cannot comment on its correctness. I rebased the patch
to current here:
http://github.com/spaetz/notmuch-all-feature/commit/3b5423fbdda5e78414e6f2e441cad5394173e155

Would that be an acceptable fix?

Also, as part of getting the useful backlog down, I propose these smallish
patches that are in my tree in the feature/misc branch (that I all grabbed from 
the mailing list):

* Add count command to manual page, Sandra Snan
  mail id:4ba29058.0f67f10a.2b59.1a73 at mx.google.com
  commit 2f5ea4c76dc9688b2520c8d64ac8617ba8a62f86
  (it was really missing)

* Fix typo in notmuch.h documentation regarding database open modes 
  mail id:1269628757-24857-1-git-send-email-michael at obberon.com
  michaelforney, comit 3262b39f58ab4865c0c0cada69955ad65fccdfd9
  (our beloved notmuch.h is WRONG!!! :-)

* Prevent data loss caused by SIGINT during notmuch new
  mail id:1269937403-8495-1-git-send-email-sojkam1 at fel.cvut.cz
  wentasah, commit dcb7a957027837f187f06d31fdcddb3740b2c20b
  (preventable data loss, has happened to him at least once)

* Do not segfault on empty mime parts, 
  mail id:1267543888-18134-1-git-send-email-madduck at madduck.net
  martin f. krafft, commit bb310c6397a94f6f59b6f93b232bedd833f96090
  (probably a bug in gmime, but we should not crash)

>   * Some library additions (move_to_first for the iterators,
+1!

All the rest souds very good.

Sebastian

Re: Plans for the 0.2 release (this week)

[Sebastian Spaeth]

First of all, thanks for the great work Carl. I have to admit I was
getting nervous about the backlog of patches, but your recent committing
binge (you did say your work patterns are bursty :-)) made me very happy.

That having said, I am glad to meet your expectation: I expect people
 to remind me of their favorite features that haven't been merged...
 :-)

   * Any further changes from the Sebastian's repository. Sebastian, I
 worked through one list I saw recently. Do you have another list to
 propose yet?

One of the things I have seen no comment on yet, is the
json_quote_str should handle non-ASCII characters patch in 
id:1267697893-sup-4...@sam.mediasupervision.de.

Right now, every char  127 will simply be suppressed, this patch fixes
this for me but I cannot comment on its correctness. I rebased the patch
to current here:
http://github.com/spaetz/notmuch-all-feature/commit/3b5423fbdda5e78414e6f2e441cad5394173e155

Would that be an acceptable fix?

Also, as part of getting the useful backlog down, I propose these smallish
patches that are in my tree in the feature/misc branch (that I all grabbed from 
the mailing list):

* Add count command to manual page, Sandra Snan
  mail id:4ba29058.0f67f10a.2b59.1...@mx.google.com
  commit 2f5ea4c76dc9688b2520c8d64ac8617ba8a62f86
  (it was really missing)

* Fix typo in notmuch.h documentation regarding database open modes 
  mail id:1269628757-24857-1-git-send-email-mich...@obberon.com
  michaelforney, comit 3262b39f58ab4865c0c0cada69955ad65fccdfd9
  (our beloved notmuch.h is WRONG!!! :-)

* Prevent data loss caused by SIGINT during notmuch new
  mail id:1269937403-8495-1-git-send-email-sojk...@fel.cvut.cz
  wentasah, commit dcb7a957027837f187f06d31fdcddb3740b2c20b
  (preventable data loss, has happened to him at least once)

* Do not segfault on empty mime parts, 
  mail id:1267543888-18134-1-git-send-email-madd...@madduck.net
  martin f. krafft, commit bb310c6397a94f6f59b6f93b232bedd833f96090
  (probably a bug in gmime, but we should not crash)

   * Some library additions (move_to_first for the iterators,
+1!

All the rest souds very good.

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

RFC: User-Agent header

[Sebastian Spaeth]

notmuch is (mostly) not responsible for sending email. However, people
using the emacs frontend use notmuch to create the reply.

Am I the only one who is sometimes curious as to what mail agents others
use? Would it be useful to insert a header to notmuch reply analog to:

User-Agent: Mutt/1.5.13 (2006-08-11)

We could reuse the same version string that we use for the release (or
the git string that was used to build notmuch). I can use this to create
nice stats :).

No patch yet, just asking if this is a good idea or not.

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

[notmuch] [Sebastian Spaeth] Pull requests

[Sebastian Spaeth]

On 2010-04-07, micah anderson wrote:
> > > The only other patch that I find absolutely crucial, that you do not
> > > include, is the 'Preserve folder information when indexing' patch which,
> > > although not perfect, does significantly change my life. 

This patch in included in my branch now. There is a branch with just
that patch over cworth/master in
http://github.com/spaetz/notmuch-all-feature/tree/issue28-search-folder-name

However, testing this, it does not seem to work for me:
I dumped and restored all mails, redoing my database and
notmuch count folder:inbox shows 2 messages that contain "folder:" in
their body. weird. I'll investigate.

Sebastian

[PATCH] * notmuch-reply.c: 542e32876 introduced a superfluous { in an if statement

[Sebastian Spaeth]

---
 notmuch-reply.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/notmuch-reply.c b/notmuch-reply.c
index e69e7a4..f26ca39 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -402,7 +402,7 @@ notmuch_reply_format_default(void *ctx, notmuch_config_t 
*config, notmuch_query_
if (from_addr == NULL)
from_addr = guess_from_received_header (config, message);

-   if (from_addr == NULL) {
+   if (from_addr == NULL)
from_addr = notmuch_config_get_user_primary_email (config);

from_addr = talloc_asprintf (ctx, "%s <%s>",
-- 
1.6.3.3

[PATCH] * notmuch-reply.c: 542e32876 introduced a superfluous { in an if statement

[Sebastian Spaeth]

---
 notmuch-reply.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/notmuch-reply.c b/notmuch-reply.c
index e69e7a4..f26ca39 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -402,7 +402,7 @@ notmuch_reply_format_default(void *ctx, notmuch_config_t 
*config, notmuch_query_
if (from_addr == NULL)
from_addr = guess_from_received_header (config, message);
 
-   if (from_addr == NULL) {
+   if (from_addr == NULL)
from_addr = notmuch_config_get_user_primary_email (config);
 
from_addr = talloc_asprintf (ctx, %s %s,
-- 
1.6.3.3

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

Re: [notmuch] [Sebastian Spaeth] Pull requests

[Sebastian Spaeth]

On 2010-04-07, micah anderson wrote:
   The only other patch that I find absolutely crucial, that you do not
   include, is the 'Preserve folder information when indexing' patch which,
   although not perfect, does significantly change my life. 

This patch in included in my branch now. There is a branch with just
that patch over cworth/master in
http://github.com/spaetz/notmuch-all-feature/tree/issue28-search-folder-name

However, testing this, it does not seem to work for me:
I dumped and restored all mails, redoing my database and
notmuch count folder:inbox shows 2 messages that contain folder: in
their body. weird. I'll investigate.

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

[PATCH] Derive version numbers from git

[Sebastian Spaeth]

On 2010-04-06, Michal Sojka wrote:
> I often have several versions of notmuch compiled and it would be very
> helpful to be able to distinguish between them. Git has a very nice
> feature to make intermediate numbering automatic and unambiguous so
> let's use it here.

But, there are people without git installed that download the release
tarball. So if this patch makes it, we need to replace this with a
static version number when baking a release tar.

Sebastian

[notmuch] vala, this is notmuch. notmuch, this is vala

[Sebastian Spaeth]

On Mon, 5 Apr 2010 14:50:04 +0100, Enrico Zini  wrote:
> Now I use "lbdb", which gets very slow as time goes. You idea creates a
> most definitely superior system.

You can actually use both :): Do check out the patch on the mailing list
to combine the notmuch address lookup with bbdb via EUDC. It works nice
for me. Although the notmuch address lookup works so well for me that I
basically never get a fallback to bbdb.

If pure email addresses is all you need (no real names yet), the above
code works well when integrated via EUDC.

Sebastian

[PATCH] notmuch.el: Make notmuch-show buffer name first subject, instead of thread-id (supersedes V1--3)

[Sebastian Spaeth]

From: Jesse Rosenthal <jrosent...@jhu.edu>

Change the buffer name to a uniquified subject of the thread (i.e. the
subject of the first message in the thread) instead of the thread-id. This
is more meaningful to the user, and will make it easier to scroll through
numerous open buffers.

Note that this patch adds an optional `buffer-name' argument to notmuch
show.

This version supersedes V1--3 of this patch. It ensures that the buffer
names are unique, and that the `notmuch-show' command can still be used
 interactively (fixing embarassing bugs in V2 and V3 which prevented that)

Signed-off-by: Jesse Rosenthal 
Signed-off-by: Sebastian Spaeth 
---
 emacs/notmuch-show.el |   11 ---
 emacs/notmuch.el  |   14 --
 2 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index cc1f905..ed95afb 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -959,7 +959,7 @@ All currently available key bindings:
  (lambda()
(hl-line-mode 1) ))

-(defun notmuch-show (thread-id  parent-buffer query-context)
+(defun notmuch-show (thread-id  parent-buffer query-context 
buffer-name)
   "Run \"notmuch show\" with the given thread ID and display results.

 The optional PARENT-BUFFER is the notmuch-search buffer from
@@ -967,9 +967,14 @@ which this notmuch-show command was executed, (so that the 
next
 thread from that buffer can be show when done with this one).

 The optional QUERY-CONTEXT is a notmuch search term. Only messages from the 
thread
-matching this search term are shown if non-nil. "
+matching this search term are shown if non-nil.
+
+The optional BUFFER-NAME provides the neame of the buffer in which the message 
thread is shown. If it is nil (which occurs when the command is called 
interactively) the argument to the function is used. "
   (interactive "sNotmuch show: ")
-  (let ((buffer (get-buffer-create (concat "*notmuch-show-" thread-id "*"
+  (when (null buffer-name)
+(setq buffer-name (concat "*notmuch-" thread-id "*")))
+  (let* ((thread-buffer-name (generate-new-buffer-name buffer-name))
+(buffer (get-buffer-create thread-buffer-name)))
 (switch-to-buffer buffer)
 (notmuch-show-mode)
 (set (make-local-variable 'notmuch-show-parent-buffer) parent-buffer)
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 5e479d6..ca0b6e0 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -404,9 +404,19 @@ Complete list of currently available key bindings:
 (defun notmuch-search-show-thread ()
   "Display the currently selected thread."
   (interactive)
-  (let ((thread-id (notmuch-search-find-thread-id)))
+  (let ((thread-id (notmuch-search-find-thread-id))
+   (subject (notmuch-search-find-subject))
+   buffer-name)
+(when (string-match "^[ \t]*$" subject)
+  (setq subject "[No Subject]"))
+(setq buffer-name (concat "*"
+ (truncate-string-to-width subject 32 nil nil t)
+ "*"))
 (if (> (length thread-id) 0)
-   (notmuch-show thread-id (current-buffer) notmuch-search-query-string)
+   (notmuch-show thread-id
+ (current-buffer)
+ notmuch-search-query-string
+ buffer-name)
   (error "End of search results"

 (defun notmuch-search-reply-to-thread ()
-- 
1.6.3.3

[notmuch] [PATCH V4] notmuch.el: Make notmuch-show buffer name first subject, instead of thread-id (supersedes V1--3)

[Sebastian Spaeth]

On Sat, 06 Mar 2010 09:20:21 -0500, Jesse Rosenthal  
wrote:
> Change the buffer name to a uniquified subject of the thread (i.e. the
> subject of the first message in the thread) instead of the thread-id. This
> is more meaningful to the user, and will make it easier to scroll through
> numerous open buffers.

I have been using this patch since it was posted and find it very
useful. However, it won't apply anymore due to the code shuffling. I'll
reply to this message and send a rebased version that applies to current
cworth/master.

Sebastian

[PATCH 2/2] notmuch.el: Colour cited regions and signatures with message-cited-text-face

[Sebastian Spaeth]

From: David Edmondson <d...@dme.org>

Patch from mail id:1266226909-19360-1-git-send-email-dme at dme.org with a fix 
in id:873a12hl3f.fsf at aw.hh.sledj.net

Signed-off-by: Sebastian Spaeth 
---
 emacs/notmuch-show.el |   18 ++
 1 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index f172f6b..353b57d 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -708,14 +708,16 @@ is what to put on the button."
(let* ((sig-start (match-beginning 0))
   (sig-end (match-end 0))
   (sig-lines (1- (count-lines sig-start end
- (if (<= sig-lines notmuch-show-signature-lines-max)
- (notmuch-show-region-to-button
-  sig-start
-  end
-  "signature"
-  indent
-  (format notmuch-show-signature-button-format sig-lines)
-  ))
+(if (<= sig-lines notmuch-show-signature-lines-max)
+  (progn
+(overlay-put (make-overlay sig-start end) 'face 
'message-cited-text-face)
+(notmuch-show-region-to-button
+ sig-start
+ end
+ "signature"
+ indent
+ (format notmuch-show-signature-button-format sig-lines)
+ )))

 (defun notmuch-show-markup-part (beg end depth)
   (if (re-search-forward notmuch-show-part-begin-regexp nil t)
-- 
1.6.3.3

[PATCH 1/2] notmuch.el: Allow citation suffixes to be shown as well as prefixes.

[Sebastian Spaeth]

From: David Edmondson <d...@dme.org>

In many conversations the last few lines of a citation are more
interesting than the first few lines, hence allow those to be shown if
desired.

Modify the face used for the citation button to distinguish it from
the surrounding citation.

Signed-off-by: Sebastian Spaeth 
---
 emacs/notmuch-show.el |   36 +---
 1 files changed, 25 insertions(+), 11 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index cc1f905..f172f6b 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -111,10 +111,20 @@ Can use up to one integer format parameter, i.e. %d")
   "Maximum length of signature that will be hidden by default.")

 (defvar notmuch-show-citation-lines-prefix 4
-  "Always show at least this many lines of a citation.
+  "Always show at least this many lines at the start of a citation.

-If there is one more line, show that, otherwise collapse
-remaining lines into a button.")
+If there is one more line than the sum of
+`notmuch-show-citation-lines-prefix' and
+`notmuch-show-citation-lines-suffix', show that, otherwise
+collapse remaining lines into a button.")
+
+(defvar notmuch-show-citation-lines-suffix 0
+  "Always show at least this many lines at the end of a citation.
+
+If there is one more line than the sum of
+`notmuch-show-citation-lines-prefix' and
+`notmuch-show-citation-lines-suffix', show that, otherwise
+collapse remaining lines into a button.")

 (defvar notmuch-show-message-begin-regexp"\fmessage{")
 (defvar notmuch-show-message-end-regexp  "\fmessage}")
@@ -679,16 +689,20 @@ is what to put on the button."
   (let* ((cite-start (match-beginning 0))
 (cite-end  (match-end 0))
 (cite-lines (count-lines cite-start cite-end)))
-   (when (> cite-lines (1+ notmuch-show-citation-lines-prefix))
+   (overlay-put (make-overlay cite-start cite-end) 'face 
'message-cited-text-face)
+   (when (> cite-lines (1+ (+ notmuch-show-citation-lines-prefix 
notmuch-show-citation-lines-suffix)))
  (goto-char cite-start)
  (forward-line notmuch-show-citation-lines-prefix)
- (notmuch-show-region-to-button
-  (point) cite-end
-  "citation"
-  indent
-  (format notmuch-show-citation-button-format
-  (- cite-lines notmuch-show-citation-lines-prefix))
-  
+ (let ((hidden-start (point)))
+   (goto-char cite-end)
+   (forward-line (- notmuch-show-citation-lines-suffix))
+   (notmuch-show-region-to-button
+hidden-start (point)
+"citation"
+indent
+(format notmuch-show-citation-button-format
+(- cite-lines notmuch-show-citation-lines-prefix 
notmuch-show-citation-lines-suffix))
+)
 (if (and (< (point) end)
 (re-search-forward signature-regexp end t))
(let* ((sig-start (match-beginning 0))
-- 
1.6.3.3

[notmuch] [PATCH] notmuch.el: Allow citation suffixes to be shown as well as prefixes.

[Sebastian Spaeth]

On Wed, 17 Feb 2010 10:51:51 +, David Edmondson  wrote:
> In many conversations the last few lines of a citation are more
> interesting than the first few lines, hence allow those to be shown if
> desired.
> 
> Modify the face used for the citation button to distinguish it from
> the surrounding citation.

I've been using this patch and don't want to lose it. However, as it
does not apply anymore due to the file moving, I'll reply with 2 updated
patches that produce nicer citations.

Sebastian

[PATCH 2/2] notmuch.el: Add support for reply-to sender

[Sebastian Spaeth]

From: Aneesh Kumar K.V <aneesh.ku...@gmail.com>

Add key binding to do a reply-to sender. This is mapped to 'R'

Signed-off-by: Aneesh Kumar K.V 
Signed-off-by: Sebastian Spaeth 
---
 emacs/notmuch-show.el |   21 -
 1 files changed, 20 insertions(+), 1 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index cc1f905..3d89861 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -63,7 +63,8 @@
 (define-key map "s" 'notmuch-search)
 (define-key map "m" 'message-mail)
 (define-key map "f" 'notmuch-show-forward-current)
-(define-key map "r" 'notmuch-show-reply)
+(define-key map "r" 'notmuch-show-reply-all)
+(define-key map "R" 'notmuch-show-reply)
 (define-key map "|" 'notmuch-show-pipe-message)
 (define-key map "w" 'notmuch-show-save-attachments)
 (define-key map "V" 'notmuch-show-view-raw-message)
@@ -360,10 +361,28 @@ buffer."
   mm-handle (> (notmuch-count-attachments mm-handle) 1
   (message "Done"))

+(defun notmuch-recipient-reply (recipient query-string)
+  (switch-to-buffer (generate-new-buffer "notmuch-draft"))
+  (call-process notmuch-command nil t nil "reply"
+   (concat "--recipient=" recipient) query-string)
+  (message-insert-signature)
+  (goto-char (point-min))
+  (if (re-search-forward "^$" nil t)
+  (progn
+   (insert "--text follows this line--")
+   (forward-line)))
+  (message-mode))
+
 (defun notmuch-show-reply ()
   "Begin composing a reply to the current message in a new buffer."
   (interactive)
   (let ((message-id (notmuch-show-get-message-id)))
+(notmuch-recipient-reply "sender" message-id)))
+
+(defun notmuch-show-reply-all ()
+  "Begin composing a reply to the current message in a new buffer."
+  (interactive)
+  (let ((message-id (notmuch-show-get-message-id)))
 (notmuch-reply message-id)))

 (defun notmuch-show-forward-current ()
-- 
1.6.3.3

[PATCH 1/2] notmuch-reply: Add support for replying only to sender

[Sebastian Spaeth]

From: Aneesh Kumar K.V 

This patch add --recipient=all|sender option

Signed-off-by: Aneesh Kumar K.V 
---
 notmuch-client.h |2 +
 notmuch-reply.c  |   55 -
 2 files changed, 43 insertions(+), 14 deletions(-)

diff --git a/notmuch-client.h b/notmuch-client.h
index d36b9ec..3ca4b32 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -73,6 +73,8 @@
 #define STRNCMP_LITERAL(var, literal) \
 strncmp ((var), (literal), sizeof (literal) - 1)

+#define NOTMUCH_REPLY_ALL   0x1
+#define NOTMUCH_REPLY_SENDER_ONLY 0x2
 static inline void
 chomp_newline (char *str)
 {
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 6c15536..e8a0820 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -232,20 +232,37 @@ reply_to_header_is_redundant (notmuch_message_t *message)
 static const char *
 add_recipients_from_message (GMimeMessage *reply,
 notmuch_config_t *config,
-notmuch_message_t *message)
+notmuch_message_t *message,
+int reply_options)
 {
-struct {
+struct reply_to_map {
const char *header;
const char *fallback;
GMimeRecipientType recipient_type;
-} reply_to_map[] = {
+} ;
+const char *from_addr = NULL;
+unsigned int i;
+struct reply_to_map *reply_to_map;
+
+struct reply_to_map reply_to_map_all[] = {
{ "reply-to", "from", GMIME_RECIPIENT_TYPE_TO  },
{ "to", NULL, GMIME_RECIPIENT_TYPE_TO  },
{ "cc", NULL, GMIME_RECIPIENT_TYPE_CC  },
-   { "bcc",NULL, GMIME_RECIPIENT_TYPE_BCC }
+   { "bcc",NULL, GMIME_RECIPIENT_TYPE_BCC },
+   {  NULL,NULL, 0 }
 };
-const char *from_addr = NULL;
-unsigned int i;
+
+/* we try from first and then reply-to */
+struct reply_to_map reply_to_map_sender[] = {
+   { "from", "reply-to", GMIME_RECIPIENT_TYPE_TO  },
+   {  NULL,NULL, 0 }
+};
+
+if (reply_options == NOTMUCH_REPLY_SENDER_ONLY) {
+   reply_to_map = reply_to_map_sender;
+} else {
+   reply_to_map = reply_to_map_all;
+}

 /* Some mailing lists munge the Reply-To header despite it being A Bad
  * Thing, see http://www.unicom.com/pw/reply-to-harmful.html
@@ -263,7 +280,7 @@ add_recipients_from_message (GMimeMessage *reply,
reply_to_map[0].fallback = NULL;
 }

-for (i = 0; i < ARRAY_SIZE (reply_to_map); i++) {
+for (i = 0; reply_to_map[i].header; i++) {
const char *addr, *recipients;

recipients = notmuch_message_get_header (message,
@@ -283,7 +300,7 @@ add_recipients_from_message (GMimeMessage *reply,
 }

 static int
-notmuch_reply_format_default(void *ctx, notmuch_config_t *config, 
notmuch_query_t *query)
+notmuch_reply_format_default(void *ctx, notmuch_config_t *config, 
notmuch_query_t *query, int reply_options)
 {
 GMimeMessage *reply;
 notmuch_messages_t *messages;
@@ -311,7 +328,7 @@ notmuch_reply_format_default(void *ctx, notmuch_config_t 
*config, notmuch_query_
subject = talloc_asprintf (ctx, "Re: %s", subject);
g_mime_message_set_subject (reply, subject);

-   from_addr = add_recipients_from_message (reply, config, message);
+   from_addr = add_recipients_from_message (reply, config, message, 
reply_options);

if (from_addr == NULL)
from_addr = notmuch_config_get_user_primary_email (config);
@@ -359,7 +376,7 @@ notmuch_reply_format_default(void *ctx, notmuch_config_t 
*config, notmuch_query_

 /* This format is currently tuned for a git send-email --notmuch hook */
 static int
-notmuch_reply_format_headers_only(void *ctx, notmuch_config_t *config, 
notmuch_query_t *query)
+notmuch_reply_format_headers_only(void *ctx, notmuch_config_t *config, 
notmuch_query_t *query, int reply_options)
 {
 GMimeMessage *reply;
 notmuch_messages_t *messages;
@@ -399,7 +416,7 @@ notmuch_reply_format_headers_only(void *ctx, 
notmuch_config_t *config, notmuch_q
g_mime_object_set_header (GMIME_OBJECT (reply),
  "References", references);

-   (void)add_recipients_from_message (reply, config, message);
+   (void)add_recipients_from_message (reply, config, message, 
reply_options);

g_mime_object_set_header (GMIME_OBJECT (reply), "Bcc",
   notmuch_config_get_user_primary_email (config));
@@ -423,8 +440,8 @@ notmuch_reply_command (void *ctx, int argc, char *argv[])
 notmuch_database_t *notmuch;
 notmuch_query_t *query;
 char *opt, *query_string;
-int i, ret = 0;
-int (*reply_format_func)(void *ctx, notmuch_config_t *config, 
notmuch_query_t *query);
+int i, ret = 0, reply_to = NOTMUCH_REPLY_ALL;
+int (*reply_format_func)(void *ctx, notmuch_config_t *config, 
notmuch_query_t *query, int reply_options);

 reply_format_func = 

[notmuch] [PATCH -V2 1/2] notmuch-reply: Add support for replying only to sender

[Sebastian Spaeth]

I just rebased these two patches as the files have been moved around. I
use those patches and they work fine for me, by the way. Patches will
arrive in a second as reply to this message.

Sebastian

Re: [notmuch] [PATCH] notmuch.el: Allow citation suffixes to be shown as well as prefixes.

[Sebastian Spaeth]

On Wed, 17 Feb 2010 10:51:51 +, David Edmondson d...@dme.org wrote:
 In many conversations the last few lines of a citation are more
 interesting than the first few lines, hence allow those to be shown if
 desired.
 
 Modify the face used for the citation button to distinguish it from
 the surrounding citation.

I've been using this patch and don't want to lose it. However, as it
does not apply anymore due to the file moving, I'll reply with 2 updated
patches that produce nicer citations.

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

[PATCH 1/2] notmuch.el: Allow citation suffixes to be shown as well as prefixes.

[Sebastian Spaeth]

From: David Edmondson d...@dme.org

In many conversations the last few lines of a citation are more
interesting than the first few lines, hence allow those to be shown if
desired.

Modify the face used for the citation button to distinguish it from
the surrounding citation.

Signed-off-by: Sebastian Spaeth sebast...@sspaeth.de
---
 emacs/notmuch-show.el |   36 +---
 1 files changed, 25 insertions(+), 11 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index cc1f905..f172f6b 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -111,10 +111,20 @@ Can use up to one integer format parameter, i.e. %d)
   Maximum length of signature that will be hidden by default.)
 
 (defvar notmuch-show-citation-lines-prefix 4
-  Always show at least this many lines of a citation.
+  Always show at least this many lines at the start of a citation.
 
-If there is one more line, show that, otherwise collapse
-remaining lines into a button.)
+If there is one more line than the sum of
+`notmuch-show-citation-lines-prefix' and
+`notmuch-show-citation-lines-suffix', show that, otherwise
+collapse remaining lines into a button.)
+
+(defvar notmuch-show-citation-lines-suffix 0
+  Always show at least this many lines at the end of a citation.
+
+If there is one more line than the sum of
+`notmuch-show-citation-lines-prefix' and
+`notmuch-show-citation-lines-suffix', show that, otherwise
+collapse remaining lines into a button.)
 
 (defvar notmuch-show-message-begin-regexp\fmessage{)
 (defvar notmuch-show-message-end-regexp  \fmessage})
@@ -679,16 +689,20 @@ is what to put on the button.
   (let* ((cite-start (match-beginning 0))
 (cite-end  (match-end 0))
 (cite-lines (count-lines cite-start cite-end)))
-   (when ( cite-lines (1+ notmuch-show-citation-lines-prefix))
+   (overlay-put (make-overlay cite-start cite-end) 'face 
'message-cited-text-face)
+   (when ( cite-lines (1+ (+ notmuch-show-citation-lines-prefix 
notmuch-show-citation-lines-suffix)))
  (goto-char cite-start)
  (forward-line notmuch-show-citation-lines-prefix)
- (notmuch-show-region-to-button
-  (point) cite-end
-  citation
-  indent
-  (format notmuch-show-citation-button-format
-  (- cite-lines notmuch-show-citation-lines-prefix))
-  
+ (let ((hidden-start (point)))
+   (goto-char cite-end)
+   (forward-line (- notmuch-show-citation-lines-suffix))
+   (notmuch-show-region-to-button
+hidden-start (point)
+citation
+indent
+(format notmuch-show-citation-button-format
+(- cite-lines notmuch-show-citation-lines-prefix 
notmuch-show-citation-lines-suffix))
+)
 (if (and ( (point) end)
 (re-search-forward signature-regexp end t))
(let* ((sig-start (match-beginning 0))
-- 
1.6.3.3

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

[PATCH 2/2] notmuch.el: Colour cited regions and signatures with message-cited-text-face

[Sebastian Spaeth]

From: David Edmondson d...@dme.org

Patch from mail id:1266226909-19360-1-git-send-email-...@dme.org with a fix in 
id:873a12hl3f@aw.hh.sledj.net

Signed-off-by: Sebastian Spaeth sebast...@sspaeth.de
---
 emacs/notmuch-show.el |   18 ++
 1 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index f172f6b..353b57d 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -708,14 +708,16 @@ is what to put on the button.
(let* ((sig-start (match-beginning 0))
   (sig-end (match-end 0))
   (sig-lines (1- (count-lines sig-start end
- (if (= sig-lines notmuch-show-signature-lines-max)
- (notmuch-show-region-to-button
-  sig-start
-  end
-  signature
-  indent
-  (format notmuch-show-signature-button-format sig-lines)
-  ))
+(if (= sig-lines notmuch-show-signature-lines-max)
+  (progn
+(overlay-put (make-overlay sig-start end) 'face 
'message-cited-text-face)
+(notmuch-show-region-to-button
+ sig-start
+ end
+ signature
+ indent
+ (format notmuch-show-signature-button-format sig-lines)
+ )))
 
 (defun notmuch-show-markup-part (beg end depth)
   (if (re-search-forward notmuch-show-part-begin-regexp nil t)
-- 
1.6.3.3

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

Re: [notmuch] [PATCH V4] notmuch.el: Make notmuch-show buffer name first subject, instead of thread-id (supersedes V1--3)

[Sebastian Spaeth]

On Sat, 06 Mar 2010 09:20:21 -0500, Jesse Rosenthal jrosent...@jhu.edu wrote:
 Change the buffer name to a uniquified subject of the thread (i.e. the
 subject of the first message in the thread) instead of the thread-id. This
 is more meaningful to the user, and will make it easier to scroll through
 numerous open buffers.

I have been using this patch since it was posted and find it very
useful. However, it won't apply anymore due to the code shuffling. I'll
reply to this message and send a rebased version that applies to current
cworth/master.

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

[PATCH] notmuch.el: Make notmuch-show buffer name first subject, instead of thread-id (supersedes V1--3)

[Sebastian Spaeth]

From: Jesse Rosenthal jrosent...@jhu.edu

Change the buffer name to a uniquified subject of the thread (i.e. the
subject of the first message in the thread) instead of the thread-id. This
is more meaningful to the user, and will make it easier to scroll through
numerous open buffers.

Note that this patch adds an optional `buffer-name' argument to notmuch
show.

This version supersedes V1--3 of this patch. It ensures that the buffer
names are unique, and that the `notmuch-show' command can still be used
 interactively (fixing embarassing bugs in V2 and V3 which prevented that)

Signed-off-by: Jesse Rosenthal jrosent...@jhu.edu
Signed-off-by: Sebastian Spaeth sebast...@sspaeth.de
---
 emacs/notmuch-show.el |   11 ---
 emacs/notmuch.el  |   14 --
 2 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index cc1f905..ed95afb 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -959,7 +959,7 @@ All currently available key bindings:
  (lambda()
(hl-line-mode 1) ))
 
-(defun notmuch-show (thread-id optional parent-buffer query-context)
+(defun notmuch-show (thread-id optional parent-buffer query-context 
buffer-name)
   Run \notmuch show\ with the given thread ID and display results.
 
 The optional PARENT-BUFFER is the notmuch-search buffer from
@@ -967,9 +967,14 @@ which this notmuch-show command was executed, (so that the 
next
 thread from that buffer can be show when done with this one).
 
 The optional QUERY-CONTEXT is a notmuch search term. Only messages from the 
thread
-matching this search term are shown if non-nil. 
+matching this search term are shown if non-nil.
+
+The optional BUFFER-NAME provides the neame of the buffer in which the message 
thread is shown. If it is nil (which occurs when the command is called 
interactively) the argument to the function is used. 
   (interactive sNotmuch show: )
-  (let ((buffer (get-buffer-create (concat *notmuch-show- thread-id *
+  (when (null buffer-name)
+(setq buffer-name (concat *notmuch- thread-id *)))
+  (let* ((thread-buffer-name (generate-new-buffer-name buffer-name))
+(buffer (get-buffer-create thread-buffer-name)))
 (switch-to-buffer buffer)
 (notmuch-show-mode)
 (set (make-local-variable 'notmuch-show-parent-buffer) parent-buffer)
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 5e479d6..ca0b6e0 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -404,9 +404,19 @@ Complete list of currently available key bindings:
 (defun notmuch-search-show-thread ()
   Display the currently selected thread.
   (interactive)
-  (let ((thread-id (notmuch-search-find-thread-id)))
+  (let ((thread-id (notmuch-search-find-thread-id))
+   (subject (notmuch-search-find-subject))
+   buffer-name)
+(when (string-match ^[ \t]*$ subject)
+  (setq subject [No Subject]))
+(setq buffer-name (concat *
+ (truncate-string-to-width subject 32 nil nil t)
+ *))
 (if ( (length thread-id) 0)
-   (notmuch-show thread-id (current-buffer) notmuch-search-query-string)
+   (notmuch-show thread-id
+ (current-buffer)
+ notmuch-search-query-string
+ buffer-name)
   (error End of search results
 
 (defun notmuch-search-reply-to-thread ()
-- 
1.6.3.3

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

Re: [notmuch] vala, this is notmuch. notmuch, this is vala

[Sebastian Spaeth]

On Mon, 5 Apr 2010 14:50:04 +0100, Enrico Zini enr...@enricozini.org wrote:
 Now I use lbdb, which gets very slow as time goes. You idea creates a
 most definitely superior system.

You can actually use both :): Do check out the patch on the mailing list
to combine the notmuch address lookup with bbdb via EUDC. It works nice
for me. Although the notmuch address lookup works so well for me that I
basically never get a fallback to bbdb.

If pure email addresses is all you need (no real names yet), the above
code works well when integrated via EUDC.

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

[notmuch] vala, this is notmuch. notmuch, this is vala

[Sebastian Spaeth]

I really want to replace my address book with dynamic notmuch searches
and while python gives me those in 0.3 seconds or so, I wanted better.

So I bound notmuch.so to vala (at least what I needed) and played with
the code a bit. The resulting 100 lines of vala code are here:

http://github.com/spaetz/vala-notmuch/tree/master/src

For those without vala, this is the generated C file which can be
compiled with './make' in the same directory:

http://github.com/spaetz/vala-notmuch/blob/static-sources/src/notmuch.c

Usage: "./vnotmuch Seb" will output all 'to:' addresses according to
frequency for all messages where to, cc, or bcc matches "Seb*". It also
filters with AND "from:yourprimarymailaddress". Just
"./vnotmuch" outputs all addresses that you ever sent mails to. It never
writes/modifies your db.

The only output you get are the lowercased email addresses and the
frequency, no names are preserved/output.

It is fast. This is my "./vnotmuch Seb" search over 14.5k mails with
857 mails from my primary account:
real0m0.026s
user0m0.000s
sys 0m0.020s

Just a teaser to make you interested in vala :).

Sebastian

[notmuch] cnotmuch 0.1.1 release

[Sebastian Spaeth]

On 2010-04-03, C?dric Cabessa wrote:
> libnotmuch.so is in my personal folder, I'd like to use LD_LIBRARY_PATH for
> that.
> The problem is that find_library does not read this variable, but hopefully
> CDLL does.
> 
> I suggest to not use find_library. If the library do not exist, we just have
> to catch the exception.
> The other advantage is that CDLL allow us to choose a library version
> (find_library will always take the latest).

Sounds reasonable enough. When I coded this, there was no official
library version yet, so searching for the latest sounded useful
enough. Now that we have an official shared lib, I'm just going to apply
your patch.

Thanks, hope it is useful
Sebastian

[notmuch] vala, this is notmuch. notmuch, this is vala

[Sebastian Spaeth]

I really want to replace my address book with dynamic notmuch searches
and while python gives me those in 0.3 seconds or so, I wanted better.

So I bound notmuch.so to vala (at least what I needed) and played with
the code a bit. The resulting 100 lines of vala code are here:

http://github.com/spaetz/vala-notmuch/tree/master/src

For those without vala, this is the generated C file which can be
compiled with './make' in the same directory:

http://github.com/spaetz/vala-notmuch/blob/static-sources/src/notmuch.c

Usage: ./vnotmuch Seb will output all 'to:' addresses according to
frequency for all messages where to, cc, or bcc matches Seb*. It also
filters with AND from:yourprimarymailaddress. Just
./vnotmuch outputs all addresses that you ever sent mails to. It never
writes/modifies your db.

The only output you get are the lowercased email addresses and the
frequency, no names are preserved/output.

It is fast. This is my ./vnotmuch Seb search over 14.5k mails with
857 mails from my primary account:
real0m0.026s
user0m0.000s
sys 0m0.020s

Just a teaser to make you interested in vala :).

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

Re: [notmuch] cnotmuch 0.1.1 release

[Sebastian Spaeth]

On 2010-04-03, Cédric Cabessa wrote:
 libnotmuch.so is in my personal folder, I'd like to use LD_LIBRARY_PATH for
 that.
 The problem is that find_library does not read this variable, but hopefully
 CDLL does.
 
 I suggest to not use find_library. If the library do not exist, we just have
 to catch the exception.
 The other advantage is that CDLL allow us to choose a library version
 (find_library will always take the latest).

Sounds reasonable enough. When I coded this, there was no official
library version yet, so searching for the latest sounded useful
enough. Now that we have an official shared lib, I'm just going to apply
your patch.

Thanks, hope it is useful
Sebastian
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] Notmuch shared library

[Sebastian Spaeth]

On Thu, 01 Apr 2010 00:54:16 -0700, Carl Worth  wrote:
> Finally, I'm a tiny bit annoyed that now after a fresh checkout of
> notmuch and "make" that one can't easily run ./notmuch without either
> installing the library (or fiddling with LD_LIBRARY_PATH). I've got some
> ideas on how to simplify that, but I'm not sure if any are good or worth
> it.

That was admittedly a very nice feature. And as I have proposed (but not
send any patch :-)). I would argue that a --shared and a --static option
(or whatever configure standard policy is for that) would make sense
that links notmuch either dynamically or statically.

But thanks for doing this work. Much appreciated
Sebastian

Re: [notmuch] Notmuch shared library

[Sebastian Spaeth]

On Thu, 01 Apr 2010 00:54:16 -0700, Carl Worth cwo...@cworth.org wrote:
 Finally, I'm a tiny bit annoyed that now after a fresh checkout of
 notmuch and make that one can't easily run ./notmuch without either
 installing the library (or fiddling with LD_LIBRARY_PATH). I've got some
 ideas on how to simplify that, but I'm not sure if any are good or worth
 it.

That was admittedly a very nice feature. And as I have proposed (but not
send any patch :-)). I would argue that a --shared and a --static option
(or whatever configure standard policy is for that) would make sense
that links notmuch either dynamically or statically.

But thanks for doing this work. Much appreciated
Sebastian
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] JSON based emacs UI

[Sebastian Spaeth]

On Mon, 29 Mar 2010 10:17:01 +0100, David Edmondson  wrote:
> > I fear this is not correct. I cloned notmuch from Carl's git repository,
> > and whenever I press 'RET' while the point is over the subject line, the
> > result is the same as pressing 'h': the subject information gets toggled.
> 
> Is this considered a feature that blocks people from switching to the
> JSON based UI?

nahh, that is fine.

[notmuch] JSON based emacs UI

[Sebastian Spaeth]

On Sun, 28 Mar 2010 07:46:40 +0200, Michal Sojka  wrote:
> I don't think this can be solved only in Makefile. From my look at dme's
> repo, he adds a new subcomand 'part', which is used by the UI. So if you
> want to use the new UI and your other features, you need to merge the
> things together.

I agree that notmuch and notmuch.el need to be developed deployed in
close cooperation. However, this bundling makes things a bit more
complex to untangle. I am willing to e.g. add the -part improvement to
my own branch of notmuch, but I want to follow dme's frontend closely.

> To build my version of notmuch, I use an ugly script
> (http://rtime.felk.cvut.cz/gitweb/notmuch.git/blob/refs/heads/debian-wsh:/wsh-buildpackage)
> which first does a big octopus merge to combine several features to one
> branch and then I build notmuch from there. The current state of my
> integration can be seen at
> http://rtime.felk.cvut.cz/gitweb/notmuch.git/shortlog/refs/heads/integration/features.

Interesting, but a bit more complicated that I was originally thinking off.

> This approach has a disadvantage that integration/features branch is
> often rewritten (whenever I add, remove or change a patch) so that
> others cannot track the branch. On the other side, the advantage is that
> others can easily see which patches I have applied on top of master. If
> Carl updates master, I just rerun the script and the updated integration
> branch is ready (unless there is a merge conflict).

Very nice.

Sebastian

[notmuch] [PATCH] notmuch-config: make new message tags configurable

[Sebastian Spaeth]

On Fri, 12 Mar 2010 17:13:26 -0500, Ben Gamari  
wrote:
>   /* success */
>   case NOTMUCH_STATUS_SUCCESS:
>   state->added_messages++;
> - tag_inbox_and_unread (message);
> + for (tag=state->new_tags; *tag != NULL; tag++)
> + notmuch_message_add_tag (message, *tag);

notmuch-new.c: In function 'add_files_recursive':
notmuch-new.c:465: warning: assignment from incompatible pointer typ

I was just trying to apply this (in addition to maildir based tagging)
to my branch, and I am getting a compiler warning. Any clue as to how to
fix this?

This is the exact commit:
http://github.com/spaetz/notmuch-all-feature/commit/9beead362971af818697412e9686f96078cdf925#L2R469

Sebastian

[notmuch] [PATCH] Prevent data loss caused by SIGINT during notmuch new

[Sebastian Spaeth]

> Oh, sorry. I thought it is so trivial, that I didn't even compile it for
> master. The right version is here:

Thanks, that worked fine now. I pushed it to my branch.

Sebastian

Re: [notmuch] [PATCH] Prevent data loss caused by SIGINT during notmuch new

[Sebastian Spaeth]

 Oh, sorry. I thought it is so trivial, that I didn't even compile it for
 master. The right version is here:

Thanks, that worked fine now. I pushed it to my branch.

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

Re: [notmuch] [PATCH] notmuch-config: make new message tags configurable

[Sebastian Spaeth]

On Fri, 12 Mar 2010 17:13:26 -0500, Ben Gamari bgamari.f...@gmail.com wrote:
   /* success */
   case NOTMUCH_STATUS_SUCCESS:
   state-added_messages++;
 - tag_inbox_and_unread (message);
 + for (tag=state-new_tags; *tag != NULL; tag++)
 + notmuch_message_add_tag (message, *tag);

notmuch-new.c: In function 'add_files_recursive':
notmuch-new.c:465: warning: assignment from incompatible pointer typ

I was just trying to apply this (in addition to maildir based tagging)
to my branch, and I am getting a compiler warning. Any clue as to how to
fix this?

This is the exact commit:
http://github.com/spaetz/notmuch-all-feature/commit/9beead362971af818697412e9686f96078cdf925#L2R469

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

Re: [notmuch] JSON based emacs UI

[Sebastian Spaeth]

On Mon, 29 Mar 2010 10:17:01 +0100, David Edmondson d...@dme.org wrote:
  I fear this is not correct. I cloned notmuch from Carl's git repository,
  and whenever I press 'RET' while the point is over the subject line, the
  result is the same as pressing 'h': the subject information gets toggled.
 
 Is this considered a feature that blocks people from switching to the
 JSON based UI?

nahh, that is fine.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] [PATCH] Prevent data loss caused by SIGINT during notmuch new

[Sebastian Spaeth]

On Sun, 28 Mar 2010 00:37:00 +0100, "Sebastian Spaeth"  wrote:
> On Fri, 26 Mar 2010 22:18:13 +0100, Michal Sojka  
> wrote:
> > When Ctrl-C is pressed in a wrong time during notmuch new, it can lead
> > to removal of messages from the database even if the files were not
> > removed.

CC -O2  notmuch-new.o
notmuch-new.c: In function 'add_files_recursive':
notmuch-new.c:519: error: 'add_files_state_t' has no member named 'interrupted'
make: *** [notmuch-new.o] Error 1

I have not checked the code yet, but simply applying this patch make the
compile fail.

Sebastian

[notmuch] JSON based emacs UI

[Sebastian Spaeth]

On Mon, 22 Mar 2010 14:47:39 +, David Edmondson  wrote:
> I'm pushed the first stage of a JSON based emacs UI to the repository at
> http://github.com/dme/notmuch (it's in the "master" branch).

Despite the switch to daylight savings time stealing me an hour of this
night, I managed to test your new notmuch.el.

It works really nice and I get the (unmeasured) feeling that it is
faster too (but then it might just be the lack of my additional patches
which slow things down :-)).

I have one question (which is more build related): now, I have to pull
your branch and an make install-emacs will also always compile and
install the notmuch binary from your branch, but I might want to keep my
own notmuch binary. Is it possible to just use the notmuch frontend from
your branch, but not having to install the binary? Is there such a make
target, or any other way? Should we create a repo that just contains the
frontend and not notmuch itself, so people can mix and match more
easily? (not sure what the right answer is here).

Sebastian

[notmuch] notmuchsync, now with new formula ;-)

[Sebastian Spaeth]

On Sun, 28 Mar 2010 03:22:31 +0200, Sebastian Spaeth  
wrote:

> This has changed!!!:
> --dryrun has become --dry-run for consistency with git

Ohh, one last thing, it no longer does an implicit "notmuch new"
(because that is not implemented in cnotmuch (yet?)) so call that before
after as needed.

Sebastian

[notmuch] notmuchsync, now with new formula ;-)

[Sebastian Spaeth]

Hi all, I just pushed an experimental branch to notmuchsync that uses
notmuch.so and my cnotmuch bindings. It needs some cleanup and
documentation, but it worked on my box.If you feel adventorous, get it from

git clone git at github.com:spaetz/notmuchsync.git 
The new stuff is in branch cnotmuch.

It synced my Maildir flags of all my 13k Mails in 2.5 seconds. You need
to have cnotmuch bindings installed in your python path (e.g. with sudo
easy_install cnotmuch) and a shared notmuch library (see 3 patches from
Ingmar to install a shared library).

READ THIS BEFORE YOU TRY: 
1) Make a notmuch dump backup before trying this :)
2) Run it with --dry-run and -d to get a non-action debug log of what
   would be done in this run and check if it makes sense.
3) The options -p(rune) -s(ync to maildir) -r(evsync to notmuch tags)
   are still the same. The --all option has actually become feasible
   now. (Rev|Syncing will otherwise only try to sync mails from the last 
   30 days)
4) -h/--help is your friend.

This has changed!!!:
--dryrun has become --dry-run for consistency with git

I am interested in feedback, testing and patches.

Sebastian

[notmuch] [PATCH] Prevent data loss caused by SIGINT during notmuch new

[Sebastian Spaeth]

On Fri, 26 Mar 2010 22:18:13 +0100, Michal Sojka  wrote:
> When Ctrl-C is pressed in a wrong time during notmuch new, it can lead
> to removal of messages from the database even if the files were not
> removed.

Thanks, applied in my feature-all branch.

Sebastian

[notmuch] [PATCH] Fix typo in notmuch.h documentation regarding database open modes

[Sebastian Spaeth]

On Fri, 26 Mar 2010 18:39:17 +, Michael Forney  
wrote:
> ---
>  lib/notmuch.h |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)

Thanks, applied in my feature-all branch

Sebastian

[notmuch] [Sebastian Spaeth] Pull requests

[Sebastian Spaeth]

On Thu, 25 Mar 2010 22:50:52 -0400, micah anderson  wrote:
> On Mon, 01 Mar 2010 15:57:00 +0100, "Sebastian Spaeth"  SSpaeth.de> wrote:
> 
> > From git repository git://github.com/spaetz/notmuch-all-feature.git I
> > would like to advocate the following branches for quick pulling. Each
> > contains 1 or 2 patches. They have all been based on todays
> > cworth/master, so it should be really painless.
> 
> Thanks for pulling these all together! All the ones that you propose I
> also use and would really like these to be merged as well.
> 
> The only other patch that I find absolutely crucial, that you do not
> include, is the 'Preserve folder information when indexing' patch which,
> although not perfect, does significantly change my life. 

Glad you find it useful. Yes, having the folder information would indeed
be nice. Is that patch working well for you? (Can you point me to the
mail ID of the patch you are using? There have been several versions
around).

Sebastian

Re: [notmuch] [PATCH] Fix typo in notmuch.h documentation regarding database open modes

[Sebastian Spaeth]

On Fri, 26 Mar 2010 18:39:17 +, Michael Forney mich...@obberon.com wrote:
 ---
  lib/notmuch.h |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

Thanks, applied in my feature-all branch

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

Re: [notmuch] [PATCH] Prevent data loss caused by SIGINT during notmuch new

[Sebastian Spaeth]

On Fri, 26 Mar 2010 22:18:13 +0100, Michal Sojka sojk...@fel.cvut.cz wrote:
 When Ctrl-C is pressed in a wrong time during notmuch new, it can lead
 to removal of messages from the database even if the files were not
 removed.

Thanks, applied in my feature-all branch.

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

[notmuch] notmuchsync, now with new formula ;-)

[Sebastian Spaeth]

Hi all, I just pushed an experimental branch to notmuchsync that uses
notmuch.so and my cnotmuch bindings. It needs some cleanup and
documentation, but it worked on my box.If you feel adventorous, get it from

git clone g...@github.com:spaetz/notmuchsync.git 
The new stuff is in branch cnotmuch.

It synced my Maildir flags of all my 13k Mails in 2.5 seconds. You need
to have cnotmuch bindings installed in your python path (e.g. with sudo
easy_install cnotmuch) and a shared notmuch library (see 3 patches from
Ingmar to install a shared library).

READ THIS BEFORE YOU TRY: 
1) Make a notmuch dump backup before trying this :)
2) Run it with --dry-run and -d to get a non-action debug log of what
   would be done in this run and check if it makes sense.
3) The options -p(rune) -s(ync to maildir) -r(evsync to notmuch tags)
   are still the same. The --all option has actually become feasible
   now. (Rev|Syncing will otherwise only try to sync mails from the last 
   30 days)
4) -h/--help is your friend.
   
This has changed!!!:
--dryrun has become --dry-run for consistency with git

I am interested in feedback, testing and patches.

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

[notmuch] cnotmuch 0.2.1 release (API complete)

[Sebastian Spaeth]

FYI: The python bindings for notmuch.so are now API complete and I
released them as version 0.2.1.

See:
http://pypi.python.org/pypi/cnotmuch for an overview and downloads.
http://bitbucket.org/spaetz/cnotmuch/ the source code repo/history
http://packages.python.org/cnotmuch/ the API documentation

> This means you can do "easy_install cnotmuch" on your linux box and it
> will get installed into:
> 
> /usr/local/lib/python2.x/dist-packages/
> 
> For uninstalling, you'll need to remove the "cnotmuch-0.2.1-py2.x.egg"
> file/directory and delete one entry in the "easy-install.pth" file in that
> same directory.
> 
> It needs to have a libnotmuch.so or libnotmuch.so.1 available in some
> library folder or will raise an exception when loading.
> "OSError: libnotmuch.so.1: cannot open shared object file: No such file or 
> directory"

Have fun,

Sebastian

[notmuch] cnotmuch 0.2.1 release (API complete)

[Sebastian Spaeth]

FYI: The python bindings for notmuch.so are now API complete and I
released them as version 0.2.1.

See:
http://pypi.python.org/pypi/cnotmuch for an overview and downloads.
http://bitbucket.org/spaetz/cnotmuch/ the source code repo/history
http://packages.python.org/cnotmuch/ the API documentation

 This means you can do easy_install cnotmuch on your linux box and it
 will get installed into:
 
 /usr/local/lib/python2.x/dist-packages/
 
 For uninstalling, you'll need to remove the cnotmuch-0.2.1-py2.x.egg
 file/directory and delete one entry in the easy-install.pth file in that
 same directory.
 
 It needs to have a libnotmuch.so or libnotmuch.so.1 available in some
 library folder or will raise an exception when loading.
 OSError: libnotmuch.so.1: cannot open shared object file: No such file or 
 directory

Have fun,

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

[notmuch] Using notmuch as an address book for tab-completion

[Sebastian Spaeth]

On Sat, 20 Mar 2010 22:35:42 -0400, Jesse Rosenthal  
wrote:
> There was some talk on IRC ages ago about using notmuch as an
> address-book for tab-completion in emacs message mode. Thanks to some
> great recent work (Ingmar Vanhassel's shared lib and Sebastians's
> cnotmuch python lib) I have been able to take a first step in that
> direction. I've written a python script (with some help and suggestions
> from spaetz) which can perform the address-book functionality, and a
> backend for emacs's EUDC address-lookup functionality to access the
> script.

Just testing the integration. First comment:
When I search for "Seb", the first 2 hits, I get are:

Sebastian Spaeth 
Sebastian Spaeth 

I think the version I sent you, lower-cased all email addresses. Is it
intentional to have these as 2 separate email addresses?

Sebastian

[notmuch] [PATCH] notmuch-new: Parse some maildir flags for labels

[Sebastian Spaeth]

> if I remember, there has been at least three different patches for this,
> so you are the fourth :-) You're right that it helps a lot with initial
> import. To promote my work a little bit, I use bidirectional
> synchronization between maildir flags and notmuch tags, which I sent in
> id:1268926780-20045-4-git-send-email-sojkam1 at fel.cvut.cz. I use IMAP
> clients from time to time and this helps me a lot because the IMAP
> server has almost never outdated status.

And it shows the need for such a patch :-). It doesn't hurt people who
stop using IMAP flags, and it helps those who still can't use notmuch
locally all the time...

So +1 from me to get one of the patches into mainline.

Sebastian

Re: [notmuch] [PATCH] notmuch-new: Parse some maildir flags for labels

[Sebastian Spaeth]

 if I remember, there has been at least three different patches for this,
 so you are the fourth :-) You're right that it helps a lot with initial
 import. To promote my work a little bit, I use bidirectional
 synchronization between maildir flags and notmuch tags, which I sent in
 id:1268926780-20045-4-git-send-email-sojk...@fel.cvut.cz. I use IMAP
 clients from time to time and this helps me a lot because the IMAP
 server has almost never outdated status.

And it shows the need for such a patch :-). It doesn't hurt people who
stop using IMAP flags, and it helps those who still can't use notmuch
locally all the time...

So +1 from me to get one of the patches into mainline.

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

[notmuch] Using notmuch as an address book for tab-completion

[Sebastian Spaeth]

On Mon, 22 Mar 2010 11:14:22 +0100, Ruben Pollan  
wrote:
> Nice feature. I think it should be implemented in the library. There is 
> already
> a function notmuch_database_get_all_tags, will be nice to have a function
> notmuch_database_get_all_addresses.

Actually, i don't think it's necessary to extend the library to get all
addresses, it is really trivial to get them, using the current API. As
to whether to extend the notmuch binary as to output all addresses, I
think this will be taken care of the output filtering once
implemented. e.g. get all addresses with:

notmuch show --format=json --output:to,cc,bcc ''

Sebastian

[notmuch] cnotmuch 0.1.1 release

[Sebastian Spaeth]

Hey all, given that there is at least one user of cnotmuch out there
now, I just put it up on the python package repository:
 http://pypi.python.org/pypi/cnotmuch

This means you can do "easy_install cnotmuch" on your linux box and it
will get installed into:

/usr/local/lib/python2.x/dist-packages/

For uninstalling, you'll need to remove the "cnotmuch-0.1-py2.x.egg"
directory and delete one entry in the "easy-install.pth" file in that
directory.

It needs to have a libnotmuch.so or libnotmuch.so.1 available in some
library folder or will raise an exception when loading.
"OSError: libnotmuch.so.1: cannot open shared object file: No such file or 
directory"

Have fun, and file issues at the issue tracker at
http://bitbucket.org/spaetz/cnotmuch/issues/

Sebastian

[notmuch] Using notmuch as an address book for tab-completion

[Sebastian Spaeth]

On Mon, 22 Mar 2010 00:13:57 +0100, Michal Sojka  wrote:
> On Sun, 21 Mar 2010, Sebastian Spaeth wrote:
> > That reminds me that there is still no installation tool for cnotmuch at
> > all. I'll have to have a look into that.
> 
> Hi, I have also a silly question :) Why did you call it cnotmuch? I'd
> expect such a thing to be called pynotmuch or similar. When I saw
> cnotmuch here I had to search other emails to find what it really is.
> Fortunately, with notmuch, I found it very quickly :-D.

Hi Michal,

no silly question at all ;). I found pynotmuch a bit predictive and
boring, and as this is the notmuch bindings to the C-library notmuch, I
just called it 'cnotmuch'. A "pynotmuch" would be a pure python
re-implementation in my mindset...

Just like the c-version of the StringIO module is called cStringIO. etc,
so I am not completely off the track here.

Having that said, I am not particularly attached to that name and can
easily change it. I am in the process of uploading it to pypi.python.org
though, so it will soon be available for a simple local install with
"easy_install cnotmuch".

Next to finding it, the only reference a user will usually only need is
"from cnotmuch import notmuch", the rest is just "notmuch" stuff.

Sebastian

Re: [notmuch] Using notmuch as an address book for tab-completion

[Sebastian Spaeth]

On Mon, 22 Mar 2010 00:13:57 +0100, Michal Sojka sojk...@fel.cvut.cz wrote:
 On Sun, 21 Mar 2010, Sebastian Spaeth wrote:
  That reminds me that there is still no installation tool for cnotmuch at
  all. I'll have to have a look into that.
 
 Hi, I have also a silly question :) Why did you call it cnotmuch? I'd
 expect such a thing to be called pynotmuch or similar. When I saw
 cnotmuch here I had to search other emails to find what it really is.
 Fortunately, with notmuch, I found it very quickly :-D.

Hi Michal,

no silly question at all ;). I found pynotmuch a bit predictive and
boring, and as this is the notmuch bindings to the C-library notmuch, I
just called it 'cnotmuch'. A pynotmuch would be a pure python
re-implementation in my mindset...

Just like the c-version of the StringIO module is called cStringIO. etc,
so I am not completely off the track here.

Having that said, I am not particularly attached to that name and can
easily change it. I am in the process of uploading it to pypi.python.org
though, so it will soon be available for a simple local install with
easy_install cnotmuch.

Next to finding it, the only reference a user will usually only need is
from cnotmuch import notmuch, the rest is just notmuch stuff.

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

Re: [notmuch] Using notmuch as an address book for tab-completion

[Sebastian Spaeth]

On Mon, 22 Mar 2010 11:14:22 +0100, Ruben Pollan mes...@sindominio.net wrote:
 Nice feature. I think it should be implemented in the library. There is 
 already
 a function notmuch_database_get_all_tags, will be nice to have a function
 notmuch_database_get_all_addresses.

Actually, i don't think it's necessary to extend the library to get all
addresses, it is really trivial to get them, using the current API. As
to whether to extend the notmuch binary as to output all addresses, I
think this will be taken care of the output filtering once
implemented. e.g. get all addresses with:

notmuch show --format=json --output:to,cc,bcc ''

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

[notmuch] Using notmuch as an address book for tab-completion

[Sebastian Spaeth]

On Sat, 20 Mar 2010 22:35:42 -0400, Jesse Rosenthal  
wrote:
> I've written a python script (with some help and suggestions
> from spaetz) which can perform the address-book functionality, and a
> backend for emacs's EUDC address-lookup functionality to access the
> script.

Thanks for sharing, I am very much looking forward to using that. This
is one more selling point for notmuch :-). Glad the python bindings were
of some use and I am willing to take improvement requests, if you find
some peculiarities in them.

I really look forward to integrate bbdb and notmuch addresses...

> Remember, neither of these will do you much good with the shared lib and
> cnotmuch installed.

That reminds me that there is still no installation tool for cnotmuch at
all. I'll have to have a look into that.

> To get tab completion from emacs, you have to install the script into
> your path, make it executable, and then put my eudcb-notmuch.el file
> into your load path (you should byte-compile it too). DON'T CHANGE THE
> TITLE OF THE .EL FILE! EUDC looks for a specific title based on
> protocol.

Silly question: How do I byte-compile stuff for emacs? I am a helpless noob 
when there
is no make install-emacs command. :-)

Will report back if it works. If yes, this is definitely stuff for the
notmuch help wiki.

Sebastian

[notmuch] reverse iterators

[Sebastian Spaeth]

On Sat, 20 Mar 2010 11:23:20 +0100, Ruben Pollan  
wrote:
> 
> Adds support to reverse iteration on messages, threads and tags. To revew and
> think if makes sense to include them on notmuch or wait until they have a real
> use.

/me raises arm. Real use case here! Personally, I don't need the
backwards operator (and I don't see the case where I would need to go
back very often). But a _move_to_first() for threads, messages (and
probably tags), would be really useful to me now:

Having bound notmuch.so to python, I am in a situation, where I can only
offer iteration once, with subsequent iterations failing. This is very
unexpected and very un-pythonesque. I fell myself over it:

#the below len() iterates and exhausts msgs
if len(msgs) > 0:
   for msg in msgs: print msg
   #above line fails horribly already...
else: print "No message for me!"

So, having a way to reset the iterator would be a real boon already now.

Sebastian

Re: [notmuch] reverse iterators

[Sebastian Spaeth]

On Sat, 20 Mar 2010 11:23:20 +0100, Ruben Pollan mes...@sindominio.net wrote:
 
 Adds support to reverse iteration on messages, threads and tags. To revew and
 think if makes sense to include them on notmuch or wait until they have a real
 use.

/me raises arm. Real use case here! Personally, I don't need the
backwards operator (and I don't see the case where I would need to go
back very often). But a _move_to_first() for threads, messages (and
probably tags), would be really useful to me now:

Having bound notmuch.so to python, I am in a situation, where I can only
offer iteration once, with subsequent iterations failing. This is very
unexpected and very un-pythonesque. I fell myself over it:

#the below len() iterates and exhausts msgs
if len(msgs)  0:
   for msg in msgs: print msg
   #above line fails horribly already...
else: print No message for me!

So, having a way to reset the iterator would be a real boon already now.

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

Re: [notmuch] Using notmuch as an address book for tab-completion

[Sebastian Spaeth]

On Sat, 20 Mar 2010 22:35:42 -0400, Jesse Rosenthal jrosent...@jhu.edu wrote:
 I've written a python script (with some help and suggestions
 from spaetz) which can perform the address-book functionality, and a
 backend for emacs's EUDC address-lookup functionality to access the
 script.

Thanks for sharing, I am very much looking forward to using that. This
is one more selling point for notmuch :-). Glad the python bindings were
of some use and I am willing to take improvement requests, if you find
some peculiarities in them.

I really look forward to integrate bbdb and notmuch addresses...

 Remember, neither of these will do you much good with the shared lib and
 cnotmuch installed.

That reminds me that there is still no installation tool for cnotmuch at
all. I'll have to have a look into that.
 
 To get tab completion from emacs, you have to install the script into
 your path, make it executable, and then put my eudcb-notmuch.el file
 into your load path (you should byte-compile it too). DON'T CHANGE THE
 TITLE OF THE .EL FILE! EUDC looks for a specific title based on
 protocol.

Silly question: How do I byte-compile stuff for emacs? I am a helpless noob 
when there
is no make install-emacs command. :-)

Will report back if it works. If yes, this is definitely stuff for the
notmuch help wiki.

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