[PATCH] Emacs: Add variable to toggle message indentation in a thread

[Felix Geller]

Hi,

I added a variable to toggle message indentation in Emacs.

Please let me know what you think.


Cheers,
Felix


diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index a433dec..8101c27 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -90,6 +90,11 @@ any given message."
   :group 'notmuch
   :type 'boolean)
 
+(defcustom notmuch-show-indent-messages-in-thread nil
+  "Should the messages in a thread be indented according to their respective 
depth in the thread?"
+  :group 'notmuch
+  :type 'boolean)
+
 (defcustom notmuch-show-indent-multipart nil
   "Should the sub-parts of a multipart/* part be indented?"
   ;; dme: Not sure which is a good default.
@@ -237,7 +242,9 @@ unchanged ADDRESS if parsing fails."
   "Insert a notmuch style headerline based on HEADERS for a
 message at DEPTH in the current thread."
   (let ((start (point)))
-(insert (notmuch-show-spaces-n depth)
+(insert (if notmuch-show-indent-messages-in-thread
+   (notmuch-show-spaces-n depth)
+ "")
(notmuch-show-clean-address (plist-get headers :From))
" ("
date
@@ -733,7 +740,8 @@ current buffer, if possible."
 (setq content-end (point-marker))
 
 ;; Indent according to the depth in the thread.
-(indent-rigidly content-start content-end depth)
+(when notmuch-show-indent-messages-in-thread
+  (indent-rigidly content-start content-end depth))
 
 (setq message-end (point-max-marker))
 


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

Re: [PATCH] Emacs: Add variable to toggle message indentation in a thread

[Dmitry Kurochkin]

Hi Felix.

On Mon, 11 Jul 2011 10:42:04 +0200, Felix Geller  wrote:
> Hi,
> 
> I added a variable to toggle message indentation in Emacs.
> 
> Please let me know what you think.
> 

I like the change.  Though I do not think I would use it without
chronological sorting.

Comments on the code below.

Regards,
  Dmitry

> 
> Cheers,
> Felix
> 
> 
> diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
> index a433dec..8101c27 100644
> --- a/emacs/notmuch-show.el
> +++ b/emacs/notmuch-show.el
> @@ -90,6 +90,11 @@ any given message."
>:group 'notmuch
>:type 'boolean)
>  
> +(defcustom notmuch-show-indent-messages-in-thread nil
> +  "Should the messages in a thread be indented according to their respective 
> depth in the thread?"

This line is too long and should be split.

> +  :group 'notmuch
> +  :type 'boolean)
> +
>  (defcustom notmuch-show-indent-multipart nil
>"Should the sub-parts of a multipart/* part be indented?"
>;; dme: Not sure which is a good default.
> @@ -237,7 +242,9 @@ unchanged ADDRESS if parsing fails."
>"Insert a notmuch style headerline based on HEADERS for a
>  message at DEPTH in the current thread."
>(let ((start (point)))
> -(insert (notmuch-show-spaces-n depth)
> +(insert (if notmuch-show-indent-messages-in-thread
> + (notmuch-show-spaces-n depth)
> +   "")

(if notmuch-show-indent-messages-in-thread
(insert (notmuch-show-spaces-n depth)))

Is cleaner and avoids useless empty string insert.

>   (notmuch-show-clean-address (plist-get headers :From))
>   " ("
>   date
> @@ -733,7 +740,8 @@ current buffer, if possible."
>  (setq content-end (point-marker))
>  
>  ;; Indent according to the depth in the thread.
> -(indent-rigidly content-start content-end depth)
> +(when notmuch-show-indent-messages-in-thread
> +  (indent-rigidly content-start content-end depth))

Not a big deal, but I would prefer `if' instead of `when' here.

Regards,
  Dmitry

>  
>  (setq message-end (point-max-marker))
>  
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] Emacs: Add variable to toggle message indentation in a thread

[Daniel Schoepe]

Hi Felix,

On Mon, 11 Jul 2011 10:42:04 +0200, Felix Geller  wrote:
> +(defcustom notmuch-show-indent-messages-in-thread nil
> +  "Should the messages in a thread be indented according to their respective 
> depth in the thread?"
> +  :group 'notmuch
> +  :type 'boolean)
> +

I think this should default to t, so it doesn't change the current
default behavior (which I find quite helpful).

Cheers,
Daniel


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

Re: [PATCH] Emacs: Add variable to toggle message indentation in a thread

[Felix Geller]

Hi Dmitry,

thank you for the comments. I included an updated patch that also
includes Daniel's comment regarding the default value. 

I didn't change the "when" though--not because of personal reasons
;)--but because it is used for determining indentation of multi-parts.


Cheers,
Felix



On Mon, 11 Jul 2011 12:53:04 +0400, Dmitry Kurochkin 
 wrote:
> Hi Felix.
> 
> On Mon, 11 Jul 2011 10:42:04 +0200, Felix Geller  wrote:
> > Hi,
> > 
> > I added a variable to toggle message indentation in Emacs.
> > 
> > Please let me know what you think.
> > 
> 
> I like the change.  Though I do not think I would use it without
> chronological sorting.
> 
> Comments on the code below.
> 
> Regards,
>   Dmitry
> 
> > 
> > Cheers,
> > Felix
> > 
> > 
> > diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
> > index a433dec..8101c27 100644
> > --- a/emacs/notmuch-show.el
> > +++ b/emacs/notmuch-show.el
> > @@ -90,6 +90,11 @@ any given message."
> >:group 'notmuch
> >:type 'boolean)
> >  
> > +(defcustom notmuch-show-indent-messages-in-thread nil
> > +  "Should the messages in a thread be indented according to their 
> > respective depth in the thread?"
> 
> This line is too long and should be split.
> 
> > +  :group 'notmuch
> > +  :type 'boolean)
> > +
> >  (defcustom notmuch-show-indent-multipart nil
> >"Should the sub-parts of a multipart/* part be indented?"
> >;; dme: Not sure which is a good default.
> > @@ -237,7 +242,9 @@ unchanged ADDRESS if parsing fails."
> >"Insert a notmuch style headerline based on HEADERS for a
> >  message at DEPTH in the current thread."
> >(let ((start (point)))
> > -(insert (notmuch-show-spaces-n depth)
> > +(insert (if notmuch-show-indent-messages-in-thread
> > +   (notmuch-show-spaces-n depth)
> > + "")
> 
> (if notmuch-show-indent-messages-in-thread
> (insert (notmuch-show-spaces-n depth)))
> 
> Is cleaner and avoids useless empty string insert.
> 
> > (notmuch-show-clean-address (plist-get headers :From))
> > " ("
> > date
> > @@ -733,7 +740,8 @@ current buffer, if possible."
> >  (setq content-end (point-marker))
> >  
> >  ;; Indent according to the depth in the thread.
> > -(indent-rigidly content-start content-end depth)
> > +(when notmuch-show-indent-messages-in-thread
> > +  (indent-rigidly content-start content-end depth))
> 
> Not a big deal, but I would prefer `if' instead of `when' here.
> 
> Regards,
>   Dmitry
> 
> >  
> >  (setq message-end (point-max-marker))
> >  
> > ___
> > notmuch mailing list
> > notmuch@notmuchmail.org
> > http://notmuchmail.org/mailman/listinfo/notmuch


commit f90fafdc0545a825ea4b69db5e51c2e866a4ff5e
Author: Felix Geller 
Date:   Mon Jul 11 10:39:00 2011 +0200

Added a variable to toggle message indentation for thread view in emacs.
 - includes adjustments according to comments from ML

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index a433dec..1834066 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -90,6 +90,11 @@ any given message."
   :group 'notmuch
   :type 'boolean)
 
+(defcustom notmuch-show-indent-messages-in-thread t
+  "Should messages be indented according to their depth in a thread?"
+  :group 'notmuch
+  :type 'boolean)
+
 (defcustom notmuch-show-indent-multipart nil
   "Should the sub-parts of a multipart/* part be indented?"
   ;; dme: Not sure which is a good default.
@@ -237,8 +242,9 @@ unchanged ADDRESS if parsing fails."
   "Insert a notmuch style headerline based on HEADERS for a
 message at DEPTH in the current thread."
   (let ((start (point)))
-(insert (notmuch-show-spaces-n depth)
-   (notmuch-show-clean-address (plist-get headers :From))
+(when notmuch-show-indent-messages-in-thread
+  (insert (notmuch-show-spaces-n depth)))
+(insert (notmuch-show-clean-address (plist-get headers :From))
" ("
date
") ("
@@ -733,7 +739,8 @@ current buffer, if possible."
 (setq content-end (point-marker))
 
 ;; Indent according to the depth in the thread.
-(indent-rigidly content-start content-end depth)
+(when notmuch-show-indent-messages-in-thread
+  (indent-rigidly content-start content-end depth))
 
 (setq message-end (point-max-marker))
 


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

Re: [python] querystrings as unicode literals?

[Sebastian Spaeth]

On Thu, 7 Jul 2011 12:37:00 +0100, Patrick Totzke 
 wrote:
> Hi!
> Something strange goes on when I use unicode literals as querystrings:
> Database().create_query(u'teststring') yields different results than
> Database().create_query('teststring')..
> 
> Now it should not be a problem to decode the string to whatever encoding
> is used by notmuch/xapian internally using 'teststring'.encode('utf8')
> for example. But can I reliably expect all strings in the index to be valid 
> utf8?
> 
> At any rate, I think this conversion should be made from inside the bindings.
> A query should return the same results for querystrings as string- and 
> unicode literals. 
> Any thoughts?

I hate encodings and they always confuse the heck out of me. I would
prefer if everything was always UTF8. notmuch.h actually doesn't state
which encoding the query string should be and neither did
http://xapian.org/docs/queryparser.html. ojwb said, it takes UTF-8, so
that's what we should be doing.

I'll send a patch as a reply shortly, Patrick, do you care to test if
this fixes things for you?

Sebastian


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

[PATCH] python: Encode query string as a utf-8 byte array

[Sebastian Spaeth]

If we pass in an unicode instance as query string, we would probably get
weird behavior (and indeed do so, see mail
id:"20110707113700.GA16347@megatron"). If a unicode instance is passed
in, make sure we encode it properly to an utf-8 encoded byte string.

Signed-off-by: Sebastian Spaeth 
---
Patrick, can you test, if this fixes the inconsistent behavior in a good way?

 bindings/python/notmuch/database.py |8 +---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/bindings/python/notmuch/database.py 
b/bindings/python/notmuch/database.py
index 3770b13..859fb18 100644
--- a/bindings/python/notmuch/database.py
+++ b/bindings/python/notmuch/database.py
@@ -501,7 +501,7 @@ class Query(object):
 :param db: An open database which we derive the Query from.
 :type db: :class:`Database`
 :param querystr: The query string for the message.
-:type querystr: str
+:type querystr: utf-8 encoded str or unicode
 """
 self._db = None
 self._query = None
@@ -517,7 +517,7 @@ class Query(object):
 :param db: Database to create the query from.
 :type db: :class:`Database`
 :param querystr: The query string
-:type querystr: str
+:type querystr: utf-8 encoded str or unicode
 :returns: Nothing
 :exception: :exc:`NotmuchError`
 
@@ -529,7 +529,9 @@ class Query(object):
 raise NotmuchError(STATUS.NOT_INITIALIZED)
 # create reference to parent db to keep it alive
 self._db = db
-
+if is_instance(querystr, unicode):
+# xapian takes utf-8 encoded byte arrays
+querystr = querystr.encode('utf-8')
 # create query, return None if too little mem available
 query_p = Query._create(db.db_p, querystr)
 if query_p is None:
-- 
1.7.4.1

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

[PATCH v2] python: Encode query string as a utf-8 byte array

[Sebastian Spaeth]

If we pass in an unicode instance as query string, we would probably get
weird behavior (and indeed do so, see mail
id:"20110707113700.GA16347@megatron"). If a unicode instance is passed
in, make sure we encode it properly to an utf-8 encoded byte string.

Signed-off-by: Sebastian Spaeth 
---
DOH, I should test my patches for typos before actually sending them off. This 
one should be fine.

 bindings/python/notmuch/database.py |8 +---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/bindings/python/notmuch/database.py 
b/bindings/python/notmuch/database.py
index 3770b13..84cf79b 100644
--- a/bindings/python/notmuch/database.py
+++ b/bindings/python/notmuch/database.py
@@ -501,7 +501,7 @@ class Query(object):
 :param db: An open database which we derive the Query from.
 :type db: :class:`Database`
 :param querystr: The query string for the message.
-:type querystr: str
+:type querystr: utf-8 encoded str or unicode
 """
 self._db = None
 self._query = None
@@ -517,7 +517,7 @@ class Query(object):
 :param db: Database to create the query from.
 :type db: :class:`Database`
 :param querystr: The query string
-:type querystr: str
+:type querystr: utf-8 encoded str or unicode
 :returns: Nothing
 :exception: :exc:`NotmuchError`
 
@@ -529,7 +529,9 @@ class Query(object):
 raise NotmuchError(STATUS.NOT_INITIALIZED)
 # create reference to parent db to keep it alive
 self._db = db
-
+if isinstance(querystr, unicode):
+# xapian takes utf-8 encoded byte arrays
+querystr = querystr.encode('utf-8')
 # create query, return None if too little mem available
 query_p = Query._create(db.db_p, querystr)
 if query_p is None:
-- 
1.7.4.1

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

Re: [PATCH] Emacs: Add variable to toggle message indentation in a thread

[Dmitry Kurochkin]

On Mon, 11 Jul 2011 11:24:57 +0200, Felix Geller  wrote:
> Hi Dmitry,
> 
> thank you for the comments. I included an updated patch that also
> includes Daniel's comment regarding the default value. 
> 

Another thing that would be nice to have is a test for this feature.

Regards,
  Dmitry

> I didn't change the "when" though--not because of personal reasons
> ;)--but because it is used for determining indentation of multi-parts.
> 
> 
> Cheers,
> Felix
> 
> 
> 
> On Mon, 11 Jul 2011 12:53:04 +0400, Dmitry Kurochkin 
>  wrote:
> > Hi Felix.
> > 
> > On Mon, 11 Jul 2011 10:42:04 +0200, Felix Geller  wrote:
> > > Hi,
> > > 
> > > I added a variable to toggle message indentation in Emacs.
> > > 
> > > Please let me know what you think.
> > > 
> > 
> > I like the change.  Though I do not think I would use it without
> > chronological sorting.
> > 
> > Comments on the code below.
> > 
> > Regards,
> >   Dmitry
> > 
> > > 
> > > Cheers,
> > > Felix
> > > 
> > > 
> > > diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
> > > index a433dec..8101c27 100644
> > > --- a/emacs/notmuch-show.el
> > > +++ b/emacs/notmuch-show.el
> > > @@ -90,6 +90,11 @@ any given message."
> > >:group 'notmuch
> > >:type 'boolean)
> > >  
> > > +(defcustom notmuch-show-indent-messages-in-thread nil
> > > +  "Should the messages in a thread be indented according to their 
> > > respective depth in the thread?"
> > 
> > This line is too long and should be split.
> > 
> > > +  :group 'notmuch
> > > +  :type 'boolean)
> > > +
> > >  (defcustom notmuch-show-indent-multipart nil
> > >"Should the sub-parts of a multipart/* part be indented?"
> > >;; dme: Not sure which is a good default.
> > > @@ -237,7 +242,9 @@ unchanged ADDRESS if parsing fails."
> > >"Insert a notmuch style headerline based on HEADERS for a
> > >  message at DEPTH in the current thread."
> > >(let ((start (point)))
> > > -(insert (notmuch-show-spaces-n depth)
> > > +(insert (if notmuch-show-indent-messages-in-thread
> > > + (notmuch-show-spaces-n depth)
> > > +   "")
> > 
> > (if notmuch-show-indent-messages-in-thread
> > (insert (notmuch-show-spaces-n depth)))
> > 
> > Is cleaner and avoids useless empty string insert.
> > 
> > >   (notmuch-show-clean-address (plist-get headers :From))
> > >   " ("
> > >   date
> > > @@ -733,7 +740,8 @@ current buffer, if possible."
> > >  (setq content-end (point-marker))
> > >  
> > >  ;; Indent according to the depth in the thread.
> > > -(indent-rigidly content-start content-end depth)
> > > +(when notmuch-show-indent-messages-in-thread
> > > +  (indent-rigidly content-start content-end depth))
> > 
> > Not a big deal, but I would prefer `if' instead of `when' here.
> > 
> > Regards,
> >   Dmitry
> > 
> > >  
> > >  (setq message-end (point-max-marker))
> > >  
> > > ___
> > > notmuch mailing list
> > > notmuch@notmuchmail.org
> > > http://notmuchmail.org/mailman/listinfo/notmuch
> 
> 
> commit f90fafdc0545a825ea4b69db5e51c2e866a4ff5e
> Author: Felix Geller 
> Date:   Mon Jul 11 10:39:00 2011 +0200
> 
> Added a variable to toggle message indentation for thread view in emacs.
>  - includes adjustments according to comments from ML
> 
> diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
> index a433dec..1834066 100644
> --- a/emacs/notmuch-show.el
> +++ b/emacs/notmuch-show.el
> @@ -90,6 +90,11 @@ any given message."
>:group 'notmuch
>:type 'boolean)
>  
> +(defcustom notmuch-show-indent-messages-in-thread t
> +  "Should messages be indented according to their depth in a thread?"
> +  :group 'notmuch
> +  :type 'boolean)
> +
>  (defcustom notmuch-show-indent-multipart nil
>"Should the sub-parts of a multipart/* part be indented?"
>;; dme: Not sure which is a good default.
> @@ -237,8 +242,9 @@ unchanged ADDRESS if parsing fails."
>"Insert a notmuch style headerline based on HEADERS for a
>  message at DEPTH in the current thread."
>(let ((start (point)))
> -(insert (notmuch-show-spaces-n depth)
> - (notmuch-show-clean-address (plist-get headers :From))
> +(when notmuch-show-indent-messages-in-thread
> +  (insert (notmuch-show-spaces-n depth)))
> +(insert (notmuch-show-clean-address (plist-get headers :From))
>   " ("
>   date
>   ") ("
> @@ -733,7 +739,8 @@ current buffer, if possible."
>  (setq content-end (point-marker))
>  
>  ;; Indent according to the depth in the thread.
> -(indent-rigidly content-start content-end depth)
> +(when notmuch-show-indent-messages-in-thread
> +  (indent-rigidly content-start content-end depth))
>  
>  (setq message-end (point-max-marker))
>  
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] Emacs: Add variable to toggle message indentation in a thread

[Felix Geller]

On Mon, 11 Jul 2011 13:55:24 +0400, Dmitry Kurochkin 
 wrote:
> On Mon, 11 Jul 2011 11:24:57 +0200, Felix Geller  wrote:
> > Hi Dmitry,
> > 
> > thank you for the comments. I included an updated patch that also
> > includes Daniel's comment regarding the default value. 
> > 
> 
> Another thing that would be nice to have is a test for this feature.

I'll look into it :)

Cheers,
Felix

>
> 
> Regards,
>   Dmitry
> 
> > I didn't change the "when" though--not because of personal reasons
> > ;)--but because it is used for determining indentation of multi-parts.
> > 
> > 
> > Cheers,
> > Felix
> > 
> > 
> > 
> > On Mon, 11 Jul 2011 12:53:04 +0400, Dmitry Kurochkin 
> >  wrote:
> > > Hi Felix.
> > > 
> > > On Mon, 11 Jul 2011 10:42:04 +0200, Felix Geller  
> > > wrote:
> > > > Hi,
> > > > 
> > > > I added a variable to toggle message indentation in Emacs.
> > > > 
> > > > Please let me know what you think.
> > > > 
> > > 
> > > I like the change.  Though I do not think I would use it without
> > > chronological sorting.
> > > 
> > > Comments on the code below.
> > > 
> > > Regards,
> > >   Dmitry
> > > 
> > > > 
> > > > Cheers,
> > > > Felix
> > > > 
> > > > 
> > > > diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
> > > > index a433dec..8101c27 100644
> > > > --- a/emacs/notmuch-show.el
> > > > +++ b/emacs/notmuch-show.el
> > > > @@ -90,6 +90,11 @@ any given message."
> > > >:group 'notmuch
> > > >:type 'boolean)
> > > >  
> > > > +(defcustom notmuch-show-indent-messages-in-thread nil
> > > > +  "Should the messages in a thread be indented according to their 
> > > > respective depth in the thread?"
> > > 
> > > This line is too long and should be split.
> > > 
> > > > +  :group 'notmuch
> > > > +  :type 'boolean)
> > > > +
> > > >  (defcustom notmuch-show-indent-multipart nil
> > > >"Should the sub-parts of a multipart/* part be indented?"
> > > >;; dme: Not sure which is a good default.
> > > > @@ -237,7 +242,9 @@ unchanged ADDRESS if parsing fails."
> > > >"Insert a notmuch style headerline based on HEADERS for a
> > > >  message at DEPTH in the current thread."
> > > >(let ((start (point)))
> > > > -(insert (notmuch-show-spaces-n depth)
> > > > +(insert (if notmuch-show-indent-messages-in-thread
> > > > +   (notmuch-show-spaces-n depth)
> > > > + "")
> > > 
> > > (if notmuch-show-indent-messages-in-thread
> > > (insert (notmuch-show-spaces-n depth)))
> > > 
> > > Is cleaner and avoids useless empty string insert.
> > > 
> > > > (notmuch-show-clean-address (plist-get headers :From))
> > > > " ("
> > > > date
> > > > @@ -733,7 +740,8 @@ current buffer, if possible."
> > > >  (setq content-end (point-marker))
> > > >  
> > > >  ;; Indent according to the depth in the thread.
> > > > -(indent-rigidly content-start content-end depth)
> > > > +(when notmuch-show-indent-messages-in-thread
> > > > +  (indent-rigidly content-start content-end depth))
> > > 
> > > Not a big deal, but I would prefer `if' instead of `when' here.
> > > 
> > > Regards,
> > >   Dmitry
> > > 
> > > >  
> > > >  (setq message-end (point-max-marker))
> > > >  
> > > > ___
> > > > notmuch mailing list
> > > > notmuch@notmuchmail.org
> > > > http://notmuchmail.org/mailman/listinfo/notmuch
> > 
> > 
> > commit f90fafdc0545a825ea4b69db5e51c2e866a4ff5e
> > Author: Felix Geller 
> > Date:   Mon Jul 11 10:39:00 2011 +0200
> > 
> > Added a variable to toggle message indentation for thread view in emacs.
> >  - includes adjustments according to comments from ML
> > 
> > diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
> > index a433dec..1834066 100644
> > --- a/emacs/notmuch-show.el
> > +++ b/emacs/notmuch-show.el
> > @@ -90,6 +90,11 @@ any given message."
> >:group 'notmuch
> >:type 'boolean)
> >  
> > +(defcustom notmuch-show-indent-messages-in-thread t
> > +  "Should messages be indented according to their depth in a thread?"
> > +  :group 'notmuch
> > +  :type 'boolean)
> > +
> >  (defcustom notmuch-show-indent-multipart nil
> >"Should the sub-parts of a multipart/* part be indented?"
> >;; dme: Not sure which is a good default.
> > @@ -237,8 +242,9 @@ unchanged ADDRESS if parsing fails."
> >"Insert a notmuch style headerline based on HEADERS for a
> >  message at DEPTH in the current thread."
> >(let ((start (point)))
> > -(insert (notmuch-show-spaces-n depth)
> > -   (notmuch-show-clean-address (plist-get headers :From))
> > +(when notmuch-show-indent-messages-in-thread
> > +  (insert (notmuch-show-spaces-n depth)))
> > +(insert (notmuch-show-clean-address (plist-get headers :From))
> > " ("
> > date
> > ") ("
> > @@ -733,7 +739,8 @@ current buffer, if possible."
> >  (setq content-end (point-marker))
> >  
> >  ;; Indent according to the depth in the thread.
> > -(indent-rigid

[PATCH] emacs: NEWS entry for user-defined sections

[Daniel Schoepe]

---
 NEWS |   13 +
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/NEWS b/NEWS
index f3fefad..98a6b28 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,16 @@
+Notmuch 0.7 (-MM-DD)
+===
+New emacs-interface features
+
+Customizable notmuch-hello page
+
+  The notmuch-hello page can now be customized using the
+  notmuch-hello-sections variable. It allows removing and adding
+  arbitrary sections (functions that insert UI elements).  Various
+  often-used, configurable section types are also provided. This
+  feature is also fully usable via the customize-interface. For more
+  information, see `M-x describe-variable notmuch-hello-sections'.
+
 Notmuch 0.6 (2011-07-01)
 ===
 New, general features
-- 
1.7.5.4

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

Re: notmuch Digest, Vol 20, Issue 57

[Sebastian Spaeth]

On Wed, 06 Jul 2011 20:46:48 +0200, Daniel Schoepe 
 wrote:
> One problem is that maildir doesn't support tags, so we would have to
> switch to a format that does or somehow store them in the maildir, in
> which case we would also have to adapt offlineimap or a similar tool to
> sync tags as well.

Right, Maildirs don't store them. AFAIK dovecot stores them in the
user-defined 'use-1-letter-abbrev-for-up-to-20-tags' notation or similar
for it's maildir. But there is no standard, and maildir is not the
answer. Either notmuch would have to directly interact via IMAP protocol
(outch), or some intermediary fetcher would have to store tags in some
type of database (which is what offlineimap could do at some point in
time).
 
> > Do you know what the status is of *server* support ? Because imo this *is* a
> > big deal, without real standardized server support an IMAP store for tags is
> > off the table.
> 
> Support for tags is mentioned in the RFC for IMAP, but it's optional. As
> far as I know, must servers today support them though.

I can't speak for Gmail, but all major servers, ie Cyrus, Dovecot, and
even Exchange seem to handle tags just fine.

Sebastian


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

Re: notmuch Digest, Vol 20, Issue 57

[Daniel Schoepe]

On Mon, 11 Jul 2011 15:22:24 +0200, Sebastian Spaeth  
wrote:
> > Support for tags is mentioned in the RFC for IMAP, but it's optional. As
> > far as I know, must servers today support them though.
> 
> I can't speak for Gmail, but all major servers, ie Cyrus, Dovecot, and
> even Exchange seem to handle tags just fine.

I just realized that this was a quite misleading typo, that should have
read "As far as I know, _most_ servers today support them though". 

I'd be very suprised if Gmail didn't support them. And even if not, one
could work around that by having a hypothetical tag synchroniser handle
Gmail differently and use their tagging mechanism:

http://code.google.com/apis/gmail/imap/#x-gm-labels

This would also have the added benefit of notmuch tags showing up in the
other gmail-tag-aware applications, like the web-interface.

Another issue brought up by DraX on IRC is that IMAP keywords don't
handle unicode. (Although the RFC specifies that every character except
some excluded special characters are allowed, so I guess it's
implementation-dependent).

I think the best way to go would be to extend both maildir and
offlineimap somehow to store tags and then store them as IMAP keywords /
gmail-labels in the case of Gmail on the server.

Cheers,
Daniel


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

Encodings

[Sebastian Spaeth]

Hi all,
after I was notified about how notmuch's python bindings perform
differently depending on whether we hand it (byte-based) ASCII strings
or unicode, I tried to disentangle what encodings to expect and send it
to. The answer is that things are very implicit. notmuch.h speaks of
strings but never mentions encodings, xapian docs don't mention
encodings but ojwb confirmed that it expects utf-8.

So, can be document what encoding we are expected to pass in the various
APIs and where we can guarantee to actually return UTF-8 encoded
strings? For some of the stuff we read directly from the files, eg
arbitrary headers, we can probably be least sure, but are e.g. the
returned tags always utf-8?

I would love to make the python bindings use unicode() instances in
cases where we can be sure to actually receive utf-8 encoded strings.

Encodings make my brain hurt. Unfortunately one cannot simply ignore
them.

Sebastian


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

[PATCH 0/2] lib: Don't always move from maildir new/ to maildir cur/

[Louis Rilling]

Hello,

Here is an alternative, as we discussed earlier. This is enough to keep me
using mutt's ability to show the "new" status, and to allow me to test notmuch
with my real emails. Altough my notmuch config uses

[new]
tags=new;

[maildir]
synchronize_flags=true

messages will be kept in "new/", even with

[new]
tags=inbox;unread;

[maildir]
synchronize_flags=true

as long as no maildir flags have to be changed.

The first patch can be applied independently.

Thanks,

Louis


Louis Rilling (2):
  tags_to_maildir_flags: Cleanup double assignement
  tags_to_maildir_flags: Don't rename if no flags change

 lib/message.cc |   14 +++---
 1 files changed, 11 insertions(+), 3 deletions(-)

-- 
1.7.2.5

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

[PATCH 1/2] tags_to_maildir_flags: Cleanup double assignement

[Louis Rilling]

The for loop right after already does the job.

Signed-off-by: Louis Rilling 
---
 lib/message.cc |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/lib/message.cc b/lib/message.cc
index d993cde..64b6cf8 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -1172,8 +1172,6 @@ _new_maildir_filename (void *ctx,
 if (info == NULL) {
info = filename + strlen(filename);
 } else {
-   flags = info + 3;
-
/* Loop through existing flags in filename. */
for (flags = info + 3, last_flag = 0;
 *flags;
-- 
1.7.2.5

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

[PATCH 2/2] tags_to_maildir_flags: Don't rename if no flags change

[Louis Rilling]

notmuch_message_tags_to_maildir_flags() unconditionally moves messages from
maildir directory "new/" to maildir directory "cur/", which makes messages lose
their "new" status in the MUA. However some users want to keep this "new"
status after, for instance, an auto-tagging of new messages.

However, as Austin mentioned and according to the maildir specification,
messages living in "new/" are not allowed to have flags, even if mutt allows it
to happen. For this reason, this patch prevents moving messages from "new/" to
"cur/", only if no flags have to be changed. It's hopefully enough to satisfy
mutt (and maybe other MUAs showing the "new" status) users checking the "new"
status.

Signed-off-by: Louis Rilling 
---
 lib/message.cc |   12 +++-
 1 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/lib/message.cc b/lib/message.cc
index 64b6cf8..131d99b 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -1139,7 +1139,7 @@ _get_maildir_flag_actions (notmuch_message_t *message,
  * compute the new maildir filename.
  *
  * If the existing filename is in the directory "new", the new
- * filename will be in the directory "cur".
+ * filename will be in the directory "cur", unless no flags are changed.
  *
  * After a sequence of ":2," in the filename, any subsequent
  * single-character flags will be added or removed according to the
@@ -1162,6 +1162,7 @@ _new_maildir_filename (void *ctx,
 char *filename_new, *dir;
 char flag_map[128];
 int flags_in_map = 0;
+bool flags_changed = false;
 unsigned int i;
 char *s;
 
@@ -1202,6 +1203,7 @@ _new_maildir_filename (void *ctx,
if (flag_map[flag] == 0) {
flag_map[flag] = 1;
flags_in_map++;
+   flags_changed = true;
}
 }
 
@@ -1210,9 +1212,17 @@ _new_maildir_filename (void *ctx,
if (flag_map[flag]) {
flag_map[flag] = 0;
flags_in_map--;
+   flags_changed = true;
}
 }
 
+/* No need to rename. Messages in new/ can be kept in new/.
+ * Note: We don't even try to fix buggy messages having flags and living in
+ * new/. It's not our business.
+ */
+if (!flags_changed)
+   return NULL;
+
 filename_new = (char *) talloc_size (ctx,
 info - filename +
 strlen (":2,") + flags_in_map + 1);
-- 
1.7.2.5

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

Re: Encodings

[Carl Worth]

On Mon, 11 Jul 2011 16:04:17 +0200, Sebastian Spaeth  
wrote:
> The answer is that things are very implicit. notmuch.h speaks of
> strings but never mentions encodings

Much of this was intentional on my part.

For example, I intentionally avoided restrictions on what could be
stored as a tag in the database, (other than the terminating character
implied by "string" of course).

> So, can be document what encoding we are expected to pass in the various
> APIs

Yes, let's clarify documentation wherever we need to.

> For some of the stuff we read directly from the files, eg
> arbitrary headers, we can probably be least sure

The headers should be decoded to utf-8, (via
g_mime_utils_header_decode_text), before being stored in the database.

> but are e.g. the returned tags always utf-8?

No. The tag data is returned exactly as the user presented it.

> I would love to make the python bindings use unicode() instances in
> cases where we can be sure to actually receive utf-8 encoded strings.
> 
> Encodings make my brain hurt. Unfortunately one cannot simply ignore
> them.

I think a lot of the pain here is due to some bad design decisions in
python itself. Of course, my saying that doesn't make things any easier
for you.

But do tell me what more we can do to clarify behavior or documentation.

-Carl

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


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

Re: [PATCH] Emacs: Add variable to toggle message indentation in a thread

[Jameson Graef Rollins]

On Mon, 11 Jul 2011 10:42:04 +0200, Felix Geller  wrote:
> I added a variable to toggle message indentation in Emacs.

Hi, Felix.  Thanks for submitting this patch.  I think it's a good idea.
I have a couple of comments below, a couple of which echo what Dmitry
has already pointed out.

> diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el

This patch doesn't include a commit log, which is something we generally
require.  The preferred way to send patches is with git format-patch or
send-email, both of which format patches in such a way that they can be
immediately applied to a git repo, including with the commit log.

> +(defcustom notmuch-show-indent-messages-in-thread nil
> +  "Should the messages in a thread be indented according to their respective 
> depth in the thread?"
> +  :group 'notmuch
> +  :type 'boolean)

I agres with Dmitry that this should default to 't', to be consistent
with the current default behavior.

> -(insert (notmuch-show-spaces-n depth)
> +(insert (if notmuch-show-indent-messages-in-thread
> + (notmuch-show-spaces-n depth)
> +   "")

I also agree with Dmitry's suggestion here to use the following slightly
simpler construct:

 (if notmuch-show-indent-messages-in-thread
 (insert (notmuch-show-spaces-n depth)))

Finally, as Dmitry also points out, you'll almost certainly need to
construct a test for this feature, since it constitutes a pretty big
formatting change.  It should probably test for both cases of the
customization variable.  Check out the tests in tests/emacs for
guidance.

hth.

jamie.


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

[PATCH] Feature request: nicknames for senders

[Jason Woofenden]

I implemented a feature I wanted: nicknames for the list of senders
on the search view.

At first I just added a setting with my full name and had it
replace that with "me". But then I figured it'd be better to allow
the user to specify a list of replacements, and instead made a more
general "nicknames" list.

Then I made myself a nice long dictionary to shorten the names of
folks I communicate with regularly. Mostly reducing them to first
names. Now it's much more common that I can see all the senders in
the narrow senders column.


Thoughts?


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

[PATCH] vim: add setting to shorten/fix sender names

[Jason Woofenden]

Add a new setting: g:notmuch_nicknames (dictionary)

When reformatting the list of senders in the search view, replace any names
matching keys in g:notmuch_nicknames with the corresponding values.
---
 vim/plugin/notmuch.vim |   19 ++-
 1 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/vim/plugin/notmuch.vim b/vim/plugin/notmuch.vim
index 12a0f88..5debaf6 100644
--- a/vim/plugin/notmuch.vim
+++ b/vim/plugin/notmuch.vim
@@ -103,6 +103,10 @@ let s:notmuch_compose_headers_defaults = [
 \ 'Subject'
 \ ]
 
+" To shorten/change the sender names in the search views:
+" let g:notmuch_nicknames = {'John Smith': 'me', 'Jane Smith': 'Jane'}
+
+
 " --- keyboard mapping definitions {{{1
 
 " --- --- bindings for folders mode {{{2
@@ -267,7 +271,20 @@ function! s:NM_cmd_search_fmtline(line)
 let p = split(at, '[@.]')
 let flist[p[0]] = 1
 endfor
-let from = join(keys(flist), ", ")
+if exists('g:notmuch_nicknames')
+let from_fixed = []
+for at in keys(flist)
+if has_key(g:notmuch_nicknames, at)
+call add(from_fixed, g:notmuch_nicknames[at])
+else
+call add(from_fixed, at)
+endif
+endfor
+let from = join(from_fixed, ', ')
+else
+let from = join(keys(flist), ', ')
+endif
+
 return printf("%-12s %3s %-20.20s | %s (%s)", m[2], m[3], from, m[5], 
m[6])
 endfunction
 
-- 
1.7.5.4

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

Slowness (search opens every email file?)

[Jason Woofenden]

Hi all,

I'm having a great time patching up the vim frontend, but I've got
an issue that is in the backend, and seems far above my head at
this point:

notmuch search tag:foo is slow!

(when my e-mail files are not already in the disk cache)

I saw on my activity monitor applet that it was using mostly i/o,
and started to wonder if it was opening every e-mail. I little work
with strace and searching revealed that this command was opening
many many e-mail files from my maildir(s). I spent a little while
digging around in the notmuch source, and didn't see where it was
opening the email files.

I don't think the search command should be opening the files. So my
questions:

1) Why is it opening the e-mail files? What information is being
read?

2) Do you agree that it should instead get this information from
the database?

3) How hard would it be make this fast? What would it take?

4) Who wants to do it?


I'd like it to be able to spit out 1000 threads in under a second.
Preferably under 100ms.


Thank you,-- Jason


P.S. I mean really slow... 

notmuch search tag:foo  took  0.5 seconds for 32 threads

notmuch search foo took 6.4 seconds for 130 threads

Everything's getting into my cache, so I can't easily get lots of
numbers. For a while I had a simple search (tag:foo and tag:bar)
which returned about 600 threads, and it would frequently take
seconds.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

problems with symbol hiding on Debian Squeeze i386

[David Bremner]

Julien Valroth reported on IRC that he had problems with the initial
call of 'notmuch new' crashing with

terminate called after throwing an instance of 'Xapian::InvalidArgumentError'

I confirmed that the following quick and dirty patch seems to fix the problem.

--- a/lib/Makefile.local
+++ b/lib/Makefile.local
@@ -36,7 +36,7 @@ LIBRARY_SUFFIX = so
 LINKER_NAME = libnotmuch.$(LIBRARY_SUFFIX)
 SONAME = $(LINKER_NAME).$(LIBNOTMUCH_VERSION_MAJOR)
 LIBNAME = $(SONAME).$(LIBNOTMUCH_VERSION_MINOR).$(LIBNOTMUCH_VERSION_RELEASE)
-LIBRARY_LINK_FLAG = -shared -Wl,--version-script=notmuch.sym,-soname=$(SONAME)
+LIBRARY_LINK_FLAG = -shared -Wl,-soname=$(SONAME)
 ifeq ($(LIBDIR_IN_LDCONFIG),1)
 ifeq ($(DESTDIR),)
 LIBRARY_INSTALL_POST_COMMAND=ldconfig

I haven't quite decided what to do about this yet, but I thought I'd get
this on the record, because it seems to me a few people have been having
problems with this.

FWIW, I tested with various versions of xapian and libgmime, but the
problem still exists for  gmime 2.4.25-1, and xapian 1.2.5-1, both
recompiled for squeeze.

If you install the libxapian22 from sid, then gcc and libc6 are both
upgraded, and the problem goes away (but you are not really running
squeeze anymore).  

About the only good news is that the symbol hiding test does indeed fail
on squeeze i386.

I have appended part of the backtrace, in case anyone finds it
illuminating.  As far as I can tell without line numbers, the catch in
_notmuch_message_remove_term is failing. I suppose this could be the
kind of "exceptions start mysteriously malfunctioning" that
http://gcc.gnu.org/wiki/Visibility warns about.

Xapian _seems_ to do the right thing with visisibility
declarations for these exception classes.

I don't know what, if anything to conclude from the fact that everything
seems to work fine in gcc 4.6.

backtrace:

#4  0xf7ac2442 in std::terminate() () from /usr/lib/libstdc++.so.6
#5  0xf7ac2581 in __cxa_throw () from /usr/lib/libstdc++.so.6
#6  0xf7b3fb83 in Xapian::Document::Internal::remove_term(std::string const&) ()
   from /usr/lib/sse2/libxapian.so.22
#7  0xf7b3fc76 in Xapian::Document::remove_term(std::string const&) ()
   from /usr/lib/sse2/libxapian.so.22
#8  0xf7fd5233 in _notmuch_message_remove_term ()
   from /home/bremner/software/upstream/notmuch/lib/libnotmuch.so.1
#9  0xf7fd5389 in notmuch_message_remove_tag ()
   from /home/bremner/software/upstream/notmuch/lib/libnotmuch.so.1
#10 0xf7fd63ea in notmuch_message_maildir_flags_to_tags ()
   from /home/bremner/software/upstream/notmuch/lib/libnotmuch.so.1
#11 0x08050483 in add_files_recursive ()


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

Re: [PATCH 2/2] tags_to_maildir_flags: Don't rename if no flags change

[Austin Clements]

I worry that this may compound the confusion caused by mutt's handling
of the new flag, but I suppose people aren't likely to manipulate any
of the other maildir-synchronized flags without also marking the
message as seen.  At any rate, the change is certainly correct
technically.  A few nits below.

Quoth Louis Rilling on Jul 11 at  4:36 pm:
> notmuch_message_tags_to_maildir_flags() unconditionally moves messages from
> maildir directory "new/" to maildir directory "cur/", which makes messages 
> lose
> their "new" status in the MUA. However some users want to keep this "new"
> status after, for instance, an auto-tagging of new messages.
> 
> However, as Austin mentioned and according to the maildir specification,
> messages living in "new/" are not allowed to have flags, even if mutt allows 
> it
> to happen. For this reason, this patch prevents moving messages from "new/" to
> "cur/", only if no flags have to be changed. It's hopefully enough to satisfy
> mutt (and maybe other MUAs showing the "new" status) users checking the "new"
> status.
> 
> Signed-off-by: Louis Rilling 
> ---
>  lib/message.cc |   12 +++-
>  1 files changed, 11 insertions(+), 1 deletions(-)
> 
> diff --git a/lib/message.cc b/lib/message.cc
> index 64b6cf8..131d99b 100644
> --- a/lib/message.cc
> +++ b/lib/message.cc
> @@ -1139,7 +1139,7 @@ _get_maildir_flag_actions (notmuch_message_t *message,
>   * compute the new maildir filename.
>   *
>   * If the existing filename is in the directory "new", the new
> - * filename will be in the directory "cur".
> + * filename will be in the directory "cur", unless no flags are changed.
>   *
>   * After a sequence of ":2," in the filename, any subsequent
>   * single-character flags will be added or removed according to the
> @@ -1162,6 +1162,7 @@ _new_maildir_filename (void *ctx,
>  char *filename_new, *dir;
>  char flag_map[128];
>  int flags_in_map = 0;
> +bool flags_changed = false;

The convention in notmuch is to use notmuch_bool_t, TRUE, and FALSE
(though, admittedly, I don't know why; avoiding C99-isms?)

>  unsigned int i;
>  char *s;
>  
> @@ -1202,6 +1203,7 @@ _new_maildir_filename (void *ctx,
>   if (flag_map[flag] == 0) {
>   flag_map[flag] = 1;
>   flags_in_map++;
> + flags_changed = true;
>   }
>  }
>  
> @@ -1210,9 +1212,17 @@ _new_maildir_filename (void *ctx,
>   if (flag_map[flag]) {
>   flag_map[flag] = 0;
>   flags_in_map--;
> + flags_changed = true;
>   }
>  }
>  
> +/* No need to rename. Messages in new/ can be kept in new/.
> + * Note: We don't even try to fix buggy messages having flags and living 
> in
> + * new/. It's not our business.
> + */
> +if (!flags_changed)
> + return NULL;
> +

NULL generally indicates an error in notmuch and is currently used
that way in _new_maildir_filename, so even though the caller currently
doesn't really care, I'd lean against overloading it to indicate that
the filename doesn't need to change.  Despite the slight inefficiency,
I would recommend returning talloc_strdup (ctx, filename).

>  filename_new = (char *) talloc_size (ctx,
>info - filename +
>strlen (":2,") + flags_in_map + 1);
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH v2] emacs: bad regexp @ `notmuch-search-process-filter'

[Pieter Praet]

TL;DR: I can haz regex pl0x?


I've updated the regex a bit to prevent it from choking on the whole
"parens in subject vs. parens around tags vs. parens around matching
Message-Id's" deal, but it still causes errors in the search buffer due
to the list of Message-Id's being cut off at a seemingly arbitrary point,
and this for *different* results on pretty much every refresh.

All tests pass, except for the ones I've mentioned before [1] (which
don't test anything tagging-related, just `notmuch-show'), though even
those fail to fail consistently :<. This variability can't be related to
residual files, as I always run the test suite like this:

  rm -rf /dev/shm/notmuch/* && make test OPTIONS="--root=/dev/shm/notmuch"


So, to keep this on track for 0.7 whilst keeping myself from having to
send spammerific amounts of patches, I've squashed the whole deal in
this single patch. Don't worry though, it's all quite grokkable:


notmuch-search.c

- Make `notmuch search' *only* append results with their Message-Id's
  when supplied with the "--output=summary-ids" option, to prevent a
  slew of failing tests obscuring the relevant ones.


emacs/notmuch.el

- Make `notmuch-search' run the notmuch binary with the "--output=summary-ids"
  option, to receive search results appended with their lists of Message-Id's.

- Update the regex @ `notmuch-search-process-filter' to include a new atom,
  which matches the list of Message-Id's at the end of every search result
  returned by the notmuch binary.
  To each individual result in the search buffer, this matched string is
  added as a text property called `notmuch-search-msgids'.

- Add 2 functions to return the `notmuch-search-msgids' property of search
  results: `notmuch-search-find-msgids', `notmuch-search-find-msgids-region'.

- Add a function to stash the Message-Id's of (a region of) search results:
  `notmuch-search-stash-msgids', bound to "m" in `notmuch-search-stash-map'.
  Mainly for testing purposes.

- Merge `notmuch-call-notmuch-process' into `notmuch-tag':
  `notmuch-tag' was the only thing making use of `notmuch-call-notmuch-process',
  and the extra layer of abstraction would complicate making `notmuch-tag' send
  arguments on stdin (see next point).

- Make `notmuch-tag' send its query string on stdin:
  Instead of providing the query string as a (potentially very long) command
  line argument, `notmuch-tag' now dumps it into a temporary buffer, which
  `call-process-region' sends to `notmuch-command' on stdin.
  This is needed to circumvent "$command: arg list too long" errors due
  to command line argument length limitations imposed by the kernel (ARG_MAX).

- Fix the actual bug(s) this patch series is intended to address by making
  the tagging functions procure their targets from the `notmuch-search-msgids'
  property with `notmuch-search-find-msgids-region', instead of using x:
  - `notmuch-search-add-tag-region'(x = 
`notmuch-search-find-thread-id-region')
  - `notmuch-search-remove-tag-region' (x = 
`notmuch-search-find-thread-id-region')
  - `notmuch-search-remove-tag'(x = 
`notmuch-search-find-thread-id-region')
  - `notmuch-search-operate-all'   (x = `notmuch-search-query-string')


test/emacs, test/emacs-search-operate-all, test/notmuch-test

- Expand the test suite to also cover:
  - Tagging messages with `notmuch-search-operate-all'.
  - Tagging messages to which a reply is sent. For this I also needed to
correct the title of an existing test, and add a test for sending
replies from within Emacs.


Side note:
  After playing around with Austin's new patch for a bit, I've come to the
  conclusion that making a clear distinction between matched and unmatched
  messages in the binary's output *is* the way to go, but in the case of
  `notmuch-search-operate-all', this capability shouldn't be leveraged.

  The way `notmuch-search-operate-all' currently works, i.e. operate on
  matched *messages* instead of matched *threads*, is not only counter-
  intuitive (same as it would be for `notmuch-search-add-tag' and
  `notmuch-search-remove-tag' [2]), but semantically incorrect as well:
  Its name implies operating on *all* that is visible in the current
  buffer, instead of only a subset.


Peace

[1] id:"1310307099-25197-1-git-send-email-pie...@praet.org"
[2] id:"e8c5fbf4-4dfa-461a-8f5c-6c696291a...@email.android.com"


Signed-off-by: Pieter Praet 
---
 emacs/notmuch.el  |   93 -
 notmuch-search.c  |6 ++-
 test/emacs|   49 +-
 test/emacs-search-operate-all |   29 +
 test/notmuch-test |1 +
 5 files changed, 147 insertions(+), 31 deletions(-)
 create mode 100755 test/emacs-search-operate-all

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index f11ec24..400adcc 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -226,6 +226,7 @@ For a mouse binding, return nil."
 (defvar notmuch-search-sta

Re: [PATCH v2] emacs: bad regexp @ `notmuch-search-process-filter'

[Austin Clements]

Quoth Pieter Praet on Jul 11 at 10:43 pm:
> TL;DR: I can haz regex pl0x?

Oof, what a pain.  I'm happy to change the output format of search; I
hadn't realized how difficult it would be to parse.  In fact, I'm not
sure it's even parsable by regexp, because the message ID's themselves
could contain parens.

So what would be a good format?  One possibility would be to
NULL-delimit the query part; as distasteful as I find that, this part
of the search output isn't meant for user consumption.  Though I fear
this is endemic to the dual role the search output currently plays as
both user and computer readable.

I've also got the code to do everything using document ID's instead of
message ID's.  As a side-effect, it makes the search output clean and
readily parsable since document ID's are just numbers.  Hence, there
are no quoting or escaping issues (plus the output is much more
compact).  I haven't sent this to the list yet because I haven't had a
chance to benchmark it and determine if the performance benefits make
exposing document ID's worthwhile.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: Slowness (search opens every email file?)

[Patrick Totzke]

Hi Jason,
On Mon, Jul 11, 2011 at 03:07:21PM -0400, Jason Woofenden wrote:
> notmuch search tag:foo is slow!
> 
yes, i've just used the vim ui for the first time and i agreee, its sluggish,
searching for * takes a while.

> (when my e-mail files are not already in the disk cache)
> 
> I saw on my activity monitor applet that it was using mostly i/o,
> and started to wonder if it was opening every e-mail. I little work
> with strace and searching revealed that this command was opening
> many many e-mail files from my maildir(s). I spent a little while
> digging around in the notmuch source, and didn't see where it was
> opening the email files.

I cannot reproduce this. I'm no expert, but at least the output of 
 strace vim -c ":NotMuch" 2>log
does not contain any path that matches that of my maildir.
Also, I wout be surprised if all individual mails would be read,
because for this, a search for all messages feels too fast.

> 2) Do you agree that it should instead get this information from
> the database?
agreed. And If the mail files get read on every search for you,
something is definately going wrong there.

A quick browse through notmuch.vim tells me that 
1) it doesn't use notmuchs json output, i think it should, as iirc
this api is considered 'more stable' and is easier to parse than the 
default output. More importantly,
2) the output of notmuch is copied into a list. This will of course
be slow if your query matches a lot of messages. Could this be done
by asyncronously writing to the buffer somehow?

best,
/p


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

Re: Slowness (search opens every email file?)

[Austin Clements]

On Mon, Jul 11, 2011 at 3:07 PM, Jason Woofenden  wrote:
> notmuch search tag:foo is slow!
>
> (when my e-mail files are not already in the disk cache)
>
> I saw on my activity monitor applet that it was using mostly i/o,
> and started to wonder if it was opening every e-mail. I little work
> with strace and searching revealed that this command was opening
> many many e-mail files from my maildir(s). I spent a little while
> digging around in the notmuch source, and didn't see where it was
> opening the email files.

It is opening every file to get a few headers to display in the search
output.  Istvan Marko sent an experimental patch to store these
headers in the database a while ago, though as far as I know there
hasn't been any progress cleaning it up for inclusion:
id:"m3sjsv2kw2@zsu.kismala.com" .
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 2/2] tags_to_maildir_flags: Don't rename if no flags change

[Louis Rilling]

On 11/07/11 16:07 -0400, Austin Clements wrote:
> I worry that this may compound the confusion caused by mutt's handling
> of the new flag, but I suppose people aren't likely to manipulate any
> of the other maildir-synchronized flags without also marking the
> message as seen.

Even if they don't mark the message as seen, any flag changed would move the 
message to cur/. The only buggy behavior would be from mutt, with the bug you 
mentioned about mutt putting messages with flags back to new/.

> At any rate, the change is certainly correct
> technically.  A few nits below.

They should be addressed by the follow-up patch. Just a comment below.

> 
> Quoth Louis Rilling on Jul 11 at  4:36 pm:
> > notmuch_message_tags_to_maildir_flags() unconditionally moves messages from
> > maildir directory "new/" to maildir directory "cur/", which makes messages 
> > lose
> > their "new" status in the MUA. However some users want to keep this "new"
> > status after, for instance, an auto-tagging of new messages.
> > 
> > However, as Austin mentioned and according to the maildir specification,
> > messages living in "new/" are not allowed to have flags, even if mutt 
> > allows it
> > to happen. For this reason, this patch prevents moving messages from "new/" 
> > to
> > "cur/", only if no flags have to be changed. It's hopefully enough to 
> > satisfy
> > mutt (and maybe other MUAs showing the "new" status) users checking the 
> > "new"
> > status.
> > 
> > Signed-off-by: Louis Rilling 
> > ---
> >  lib/message.cc |   12 +++-
> >  1 files changed, 11 insertions(+), 1 deletions(-)
> > 
> > diff --git a/lib/message.cc b/lib/message.cc
> > index 64b6cf8..131d99b 100644
> > --- a/lib/message.cc
> > +++ b/lib/message.cc
> > @@ -1139,7 +1139,7 @@ _get_maildir_flag_actions (notmuch_message_t *message,
> >   * compute the new maildir filename.
> >   *
> >   * If the existing filename is in the directory "new", the new
> > - * filename will be in the directory "cur".
> > + * filename will be in the directory "cur", unless no flags are changed.
> >   *
> >   * After a sequence of ":2," in the filename, any subsequent
> >   * single-character flags will be added or removed according to the
> > @@ -1162,6 +1162,7 @@ _new_maildir_filename (void *ctx,
> >  char *filename_new, *dir;
> >  char flag_map[128];
> >  int flags_in_map = 0;
> > +bool flags_changed = false;
> 
> The convention in notmuch is to use notmuch_bool_t, TRUE, and FALSE
> (though, admittedly, I don't know why; avoiding C99-isms?)

And bool is already used at another place in message.cc:

struct maildir_flag_tag {
char flag;
const char *tag;
bool inverse;
};

IIUC it should be changed to notmuch_bool_t too.

> 
> >  unsigned int i;
> >  char *s;
> >  
> > @@ -1202,6 +1203,7 @@ _new_maildir_filename (void *ctx,
> > if (flag_map[flag] == 0) {
> > flag_map[flag] = 1;
> > flags_in_map++;
> > +   flags_changed = true;
> > }
> >  }
> >  
> > @@ -1210,9 +1212,17 @@ _new_maildir_filename (void *ctx,
> > if (flag_map[flag]) {
> > flag_map[flag] = 0;
> > flags_in_map--;
> > +   flags_changed = true;
> > }
> >  }
> >  
> > +/* No need to rename. Messages in new/ can be kept in new/.
> > + * Note: We don't even try to fix buggy messages having flags and 
> > living in
> > + * new/. It's not our business.
> > + */
> > +if (!flags_changed)
> > +   return NULL;
> > +
> 
> NULL generally indicates an error in notmuch and is currently used
> that way in _new_maildir_filename, so even though the caller currently
> doesn't really care, I'd lean against overloading it to indicate that
> the filename doesn't need to change.  Despite the slight inefficiency,
> I would recommend returning talloc_strdup (ctx, filename).

Ok.

Thanks,

Louis

> 
> >  filename_new = (char *) talloc_size (ctx,
> >  info - filename +
> >  strlen (":2,") + flags_in_map + 1);
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH v2] tags_to_maildir_flags: Don't rename if no flags change

[Louis Rilling]

notmuch_message_tags_to_maildir_flags() unconditionally moves messages from
maildir directory "new/" to maildir directory "cur/", which makes messages lose
their "new" status in the MUA. However some users want to keep this "new"
status after, for instance, an auto-tagging of new messages.

However, as Austin mentioned and according to the maildir specification,
messages living in "new/" are not allowed to have flags, even if mutt allows it
to happen. For this reason, this patch prevents moving messages from "new/" to
"cur/", only if no flags have to be changed. It's hopefully enough to satisfy
mutt (and maybe other MUAs showing the "new" status) users checking the "new"
status.

Changelog:
* v2: Fix bool type as well as NULL returned despite having no errors (Austin
  Clements)

Signed-off-by: Louis Rilling 
---
 lib/message.cc |   12 +++-
 1 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/lib/message.cc b/lib/message.cc
index 64b6cf8..3f8c4ba 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -1139,7 +1139,7 @@ _get_maildir_flag_actions (notmuch_message_t *message,
  * compute the new maildir filename.
  *
  * If the existing filename is in the directory "new", the new
- * filename will be in the directory "cur".
+ * filename will be in the directory "cur", unless no flags are changed.
  *
  * After a sequence of ":2," in the filename, any subsequent
  * single-character flags will be added or removed according to the
@@ -1162,6 +1162,7 @@ _new_maildir_filename (void *ctx,
 char *filename_new, *dir;
 char flag_map[128];
 int flags_in_map = 0;
+notmuch_bool_t flags_changed = FALSE;
 unsigned int i;
 char *s;
 
@@ -1202,6 +1203,7 @@ _new_maildir_filename (void *ctx,
if (flag_map[flag] == 0) {
flag_map[flag] = 1;
flags_in_map++;
+   flags_changed = TRUE;
}
 }
 
@@ -1210,9 +1212,17 @@ _new_maildir_filename (void *ctx,
if (flag_map[flag]) {
flag_map[flag] = 0;
flags_in_map--;
+   flags_changed = TRUE;
}
 }
 
+/* No need to rename. Messages in new/ can be kept in new/.
+ * Note: We don't even try to fix buggy messages having flags and living in
+ * new/. It's not our business.
+ */
+if (!flags_changed)
+   return talloc_strdup (ctx, filename);
+
 filename_new = (char *) talloc_size (ctx,
 info - filename +
 strlen (":2,") + flags_in_map + 1);
-- 
1.7.2.5

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

Re: [PATCH 2/2] tags_to_maildir_flags: Don't rename if no flags change

[Austin Clements]

Quoth Louis Rilling on Jul 12 at 12:38 am:
> On 11/07/11 16:07 -0400, Austin Clements wrote:
> > I worry that this may compound the confusion caused by mutt's handling
> > of the new flag, but I suppose people aren't likely to manipulate any
> > of the other maildir-synchronized flags without also marking the
> > message as seen.
> 
> Even if they don't mark the message as seen, any flag changed would
> move the message to cur/. The only buggy behavior would be from
> mutt, with the bug you mentioned about mutt putting messages with
> flags back to new/.

Yes.  I was thinking of someone tagging a message as, say, flagged,
while it's still tagged unread.  Then it would change from new to old
in mutt.  OTOH, adding some other non-synchronized tag wouldn't change
it from new to old.  I don't think there is a "correct" solution; your
approach is probably the best compromise.

> > The convention in notmuch is to use notmuch_bool_t, TRUE, and FALSE
> > (though, admittedly, I don't know why; avoiding C99-isms?)
> 
> And bool is already used at another place in message.cc:
> 
>   struct maildir_flag_tag {
>   char flag;
>   const char *tag;
>   bool inverse;
>   };
> 
> IIUC it should be changed to notmuch_bool_t too.

Yes, I suppose it should (something slipped by cworth's eagle-eyed
reviews!).  Though that appears to be the sole use of bool in all of
libnotmuch.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH v2] tags_to_maildir_flags: Don't rename if no flags change

[Austin Clements]

LGTM.

Quoth Louis Rilling on Jul 12 at 12:41 am:
> notmuch_message_tags_to_maildir_flags() unconditionally moves messages from
> maildir directory "new/" to maildir directory "cur/", which makes messages 
> lose
> their "new" status in the MUA. However some users want to keep this "new"
> status after, for instance, an auto-tagging of new messages.
> 
> However, as Austin mentioned and according to the maildir specification,
> messages living in "new/" are not allowed to have flags, even if mutt allows 
> it
> to happen. For this reason, this patch prevents moving messages from "new/" to
> "cur/", only if no flags have to be changed. It's hopefully enough to satisfy
> mutt (and maybe other MUAs showing the "new" status) users checking the "new"
> status.
> 
> Changelog:
> * v2: Fix bool type as well as NULL returned despite having no errors (Austin
>   Clements)
> 
> Signed-off-by: Louis Rilling 
> ---
>  lib/message.cc |   12 +++-
>  1 files changed, 11 insertions(+), 1 deletions(-)
> 
> diff --git a/lib/message.cc b/lib/message.cc
> index 64b6cf8..3f8c4ba 100644
> --- a/lib/message.cc
> +++ b/lib/message.cc
> @@ -1139,7 +1139,7 @@ _get_maildir_flag_actions (notmuch_message_t *message,
>   * compute the new maildir filename.
>   *
>   * If the existing filename is in the directory "new", the new
> - * filename will be in the directory "cur".
> + * filename will be in the directory "cur", unless no flags are changed.
>   *
>   * After a sequence of ":2," in the filename, any subsequent
>   * single-character flags will be added or removed according to the
> @@ -1162,6 +1162,7 @@ _new_maildir_filename (void *ctx,
>  char *filename_new, *dir;
>  char flag_map[128];
>  int flags_in_map = 0;
> +notmuch_bool_t flags_changed = FALSE;
>  unsigned int i;
>  char *s;
>  
> @@ -1202,6 +1203,7 @@ _new_maildir_filename (void *ctx,
>   if (flag_map[flag] == 0) {
>   flag_map[flag] = 1;
>   flags_in_map++;
> + flags_changed = TRUE;
>   }
>  }
>  
> @@ -1210,9 +1212,17 @@ _new_maildir_filename (void *ctx,
>   if (flag_map[flag]) {
>   flag_map[flag] = 0;
>   flags_in_map--;
> + flags_changed = TRUE;
>   }
>  }
>  
> +/* No need to rename. Messages in new/ can be kept in new/.
> + * Note: We don't even try to fix buggy messages having flags and living 
> in
> + * new/. It's not our business.
> + */
> +if (!flags_changed)
> + return talloc_strdup (ctx, filename);
> +
>  filename_new = (char *) talloc_size (ctx,
>info - filename +
>strlen (":2,") + flags_in_map + 1);
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

vim front-end patches by Jason

[Jason Woofenden]

OK, everybody, here's my first set of patches. They all cleanup the
vim front-end. I started with the little stuff, to get my feet wet.

Here's what's coming:

[PATCH 1/5] vim: fix space key: now archives (did opposite)
[PATCH 2/5] vim: fix from list reformatting in search view
[PATCH 3/5] vim: fix on-screen instructions for show-signature
[PATCH 4/5] vim: fix (hack) cig/cit parsing within multipart/*
[PATCH 5/5] vim: fix citation/signature fold lengths

The first three I've sent to the debian bug-tracking system I
think. Though I've since updated the second patch to not include
the change made by the first patch.

So... use these instead.

Or if you prefer git clone/remote, or online browsing, etc.,
you can see my work here:

https://gitorious.org/jasonwoof/notmuch


That's all for now. Feedback (as always) is welcome. Especially the
type that leads to me learning something and/or my patches getting
merged upstream.


Take care,- Jason

P.S. I've looked into the key [re]mapping and I think we can
implement the notmuch mappings without screwing up the users
mappings by using the  argument to :nmap. I'll experiment
with that later.

P.P.S. These, and all future changes I submit to this project are
of course available under the terms of the GPL, version 3 or at
your option any later version. Please let me know if you'd like me
to make this sort of statement in any particular way/place.

[PATCH 2/5] vim: fix from list reformatting in search view

[Jason Woofenden]

This patch rewrites the reformatting of the from list so it shows full
capitalized names when available (without truncating them as the old code did)
and removes the pipe characters that appear between some names.

The old code appears to assume from list (the list of senders in the thread)
coming from notmuch would be e-mail addresses, but in this version it is mostly
full names. Also in this version, the names are sometimes separated by pipe
instead of comma.

For consistency with old versions, names are still truncated at the first
period. Perhaps they shouldn't be though.
---
 vim/plugin/notmuch.vim |   10 +-
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/vim/plugin/notmuch.vim b/vim/plugin/notmuch.vim
index d493580..e4b22d3 100644
--- a/vim/plugin/notmuch.vim
+++ b/vim/plugin/notmuch.vim
@@ -262,12 +262,12 @@ function! s:NM_cmd_search_fmtline(line)
 return 'ERROR PARSING: ' . a:line
 endif
 let max = g:notmuch_search_from_column_width
-let flist = []
-for at in split(m[4], ", ")
-let p = min([stridx(at, "."), stridx(at, "@")])
-call insert(flist, tolower(at[0:p - 1]))
+let flist = {}
+for at in split(m[4], '[|,] ')
+let p = split(at, '[@.]')
+let flist[p[0]] = 1
 endfor
-let from = join(flist, ", ")
+let from = join(keys(flist), ", ")
 return printf("%-12s %3s %-20.20s | %s (%s)", m[2], m[3], from, m[5], 
m[6])
 endfunction

-- 
1.7.5.4

[PATCH 1/5] vim: fix space key: now archives (did opposite)

[Jason Woofenden]

In vim, in the message view, space is supposed to remove the "unread" and
"inbox" tags, but was sometimes adding them instead.

This patch assures that they are always removed by this binding.
---
 vim/plugin/notmuch.vim |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/vim/plugin/notmuch.vim b/vim/plugin/notmuch.vim
index 768a011..d493580 100644
--- a/vim/plugin/notmuch.vim
+++ b/vim/plugin/notmuch.vim
@@ -596,7 +596,7 @@ function! s:NM_show_advance_marking_read_and_archiving()
 let filter = NM_combine_tags('tag:', advance_tags, 'OR', 
'()')
  \ + ['AND']
  \ + NM_combine_tags('', ids, 'OR', '()')
-call map(advance_tags, '"+" . v:val')
+call map(advance_tags, '"-" . v:val')
 call NM_tag(filter, advance_tags)
 call NM_show_next(1, 1)
 return
-- 
1.7.5.4

[PATCH 4/5] vim: fix (hack) cig/cit parsing within multipart/*

[Jason Woofenden]

The vim front-end isn't written to handle nested parts.

This patch doesn't change that, it just changes the code to pretend that
multipart/* sections end immediately. This makes the parsing code think that
all sections are top-level, and are thus parsed well enough.

The lovely result of this is that citation folds and signature folds now work
in text/plain parts that are within multipart/* sections. Also, all mime
section starts are now shown correctly (before some were not parsed and showed
the ugly ^L and an ID and so on from notmuch.)
---
 vim/plugin/notmuch.vim |9 -
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/vim/plugin/notmuch.vim b/vim/plugin/notmuch.vim
index 3982008..2095547 100644
--- a/vim/plugin/notmuch.vim
+++ b/vim/plugin/notmuch.vim
@@ -796,7 +796,14 @@ function! s:NM_cmd_show_parse(inlines)
 endif
 call add(info['disp'],
  \ printf('--- %s ---', in_part))
-let part_start = len(info['disp']) + 1
+" We don't yet handle nested parts, so pop
+" multipart/* immediately so text/plain
+" sub-parts are parsed properly
+if match(in_part, '^multipart/') != -1
+let in_part = ''
+else
+let part_start = len(info['disp']) + 1
+endif
 endif

 elseif in_header
-- 
1.7.5.4

[PATCH 3/5] vim: fix on-screen instructions for show-signature

[Jason Woofenden]

Also change a passed parameter to be consistent with the current binding. This
parameter appears to be unused.
---
 vim/plugin/notmuch.vim |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/vim/plugin/notmuch.vim b/vim/plugin/notmuch.vim
index e4b22d3..3982008 100644
--- a/vim/plugin/notmuch.vim
+++ b/vim/plugin/notmuch.vim
@@ -149,7 +149,7 @@ let g:notmuch_show_maps = {
 \ 'b':  ':call NM_show_fold_toggle(''b'', ''bdy'', 
!g:notmuch_show_fold_bodies)',
 \ 'c':  ':call NM_show_fold_toggle(''c'', ''cit'', 
!g:notmuch_show_fold_citations)',
 \ 'h':  ':call NM_show_fold_toggle(''h'', ''hdr'', 
!g:notmuch_show_fold_headers)',
-\ 'i':  ':call NM_show_fold_toggle(''s'', ''sig'', 
!g:notmuch_show_fold_signatures)',
+\ 'i':  ':call NM_show_fold_toggle(''i'', ''sig'', 
!g:notmuch_show_fold_signatures)',
 \
 \ 'I':  ':call NM_show_mark_read_thread()',
 \ 'a':  ':call NM_show_archive_thread()',
@@ -757,7 +757,7 @@ function! s:NM_cmd_show_parse(inlines)
 let mode_type = ''
 elseif part_end
 let foldinfo = [ mode_type, 
mode_start, outlnum-1, len(info['msgs']),
-   \ printf('[ 
%d-line signature.  Press "s" to show. ]', outlnum - mode_start) ]
+   \ printf('[ 
%d-line signature.  Press "i" to show. ]', outlnum - mode_start) ]
 let mode_type = ''
 endif
 endif
-- 
1.7.5.4

[PATCH 5/5] vim: fix citation/signature fold lengths

[Jason Woofenden]

Before they'd often miss the last line
---
 vim/plugin/notmuch.vim |   11 +++
 1 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/vim/plugin/notmuch.vim b/vim/plugin/notmuch.vim
index 2095547..12a0f88 100644
--- a/vim/plugin/notmuch.vim
+++ b/vim/plugin/notmuch.vim
@@ -747,8 +747,11 @@ function! s:NM_cmd_show_parse(inlines)
 elseif mode_type == 'cit'
 if part_end || match(line, 
g:notmuch_show_citation_regexp) == -1
 let outlnum = len(info['disp'])
-let foldinfo = [ mode_type, 
mode_start, outlnum-1, len(info['msgs']),
-   \ printf('[ 
%d-line citation.  Press "c" to show. ]', outlnum - mode_start) ]
+if !part_end
+let outlnum = outlnum 
- 1
+endif
+let foldinfo = [ mode_type, 
mode_start, outlnum, len(info['msgs']),
+   \ printf('[ 
%d-line citation.  Press "c" to show. ]', 1 + outlnum - mode_start) ]
 let mode_type = ''
 endif
 elseif mode_type == 'sig'
@@ -756,8 +759,8 @@ function! s:NM_cmd_show_parse(inlines)
 if (outlnum - mode_start) > 
g:notmuch_show_signature_lines_max
 let mode_type = ''
 elseif part_end
-let foldinfo = [ mode_type, 
mode_start, outlnum-1, len(info['msgs']),
-   \ printf('[ 
%d-line signature.  Press "i" to show. ]', outlnum - mode_start) ]
+let foldinfo = [ mode_type, 
mode_start, outlnum, len(info['msgs']),
+   \ printf('[ 
%d-line signature.  Press "i" to show. ]', 1 + outlnum - mode_start) ]
 let mode_type = ''
 endif
 endif
-- 
1.7.5.4

[PATCH] Emacs: Add variable to toggle message indentation in a thread

[Felix Geller]

Hi,

I added a variable to toggle message indentation in Emacs.

Please let me know what you think.


Cheers,
Felix


diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index a433dec..8101c27 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -90,6 +90,11 @@ any given message."
   :group 'notmuch
   :type 'boolean)

+(defcustom notmuch-show-indent-messages-in-thread nil
+  "Should the messages in a thread be indented according to their respective 
depth in the thread?"
+  :group 'notmuch
+  :type 'boolean)
+
 (defcustom notmuch-show-indent-multipart nil
   "Should the sub-parts of a multipart/* part be indented?"
   ;; dme: Not sure which is a good default.
@@ -237,7 +242,9 @@ unchanged ADDRESS if parsing fails."
   "Insert a notmuch style headerline based on HEADERS for a
 message at DEPTH in the current thread."
   (let ((start (point)))
-(insert (notmuch-show-spaces-n depth)
+(insert (if notmuch-show-indent-messages-in-thread
+   (notmuch-show-spaces-n depth)
+ "")
(notmuch-show-clean-address (plist-get headers :From))
" ("
date
@@ -733,7 +740,8 @@ current buffer, if possible."
 (setq content-end (point-marker))

 ;; Indent according to the depth in the thread.
-(indent-rigidly content-start content-end depth)
+(when notmuch-show-indent-messages-in-thread
+  (indent-rigidly content-start content-end depth))

 (setq message-end (point-max-marker))

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 202 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110711/0b97f29c/attachment.pgp>

[PATCH] Emacs: Add variable to toggle message indentation in a thread

[Dmitry Kurochkin]

Hi Felix.

On Mon, 11 Jul 2011 10:42:04 +0200, Felix Geller  wrote:
> Hi,
> 
> I added a variable to toggle message indentation in Emacs.
> 
> Please let me know what you think.
> 

I like the change.  Though I do not think I would use it without
chronological sorting.

Comments on the code below.

Regards,
  Dmitry

> 
> Cheers,
> Felix
> 
> 
> diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
> index a433dec..8101c27 100644
> --- a/emacs/notmuch-show.el
> +++ b/emacs/notmuch-show.el
> @@ -90,6 +90,11 @@ any given message."
>:group 'notmuch
>:type 'boolean)
>  
> +(defcustom notmuch-show-indent-messages-in-thread nil
> +  "Should the messages in a thread be indented according to their respective 
> depth in the thread?"

This line is too long and should be split.

> +  :group 'notmuch
> +  :type 'boolean)
> +
>  (defcustom notmuch-show-indent-multipart nil
>"Should the sub-parts of a multipart/* part be indented?"
>;; dme: Not sure which is a good default.
> @@ -237,7 +242,9 @@ unchanged ADDRESS if parsing fails."
>"Insert a notmuch style headerline based on HEADERS for a
>  message at DEPTH in the current thread."
>(let ((start (point)))
> -(insert (notmuch-show-spaces-n depth)
> +(insert (if notmuch-show-indent-messages-in-thread
> + (notmuch-show-spaces-n depth)
> +   "")

(if notmuch-show-indent-messages-in-thread
(insert (notmuch-show-spaces-n depth)))

Is cleaner and avoids useless empty string insert.

>   (notmuch-show-clean-address (plist-get headers :From))
>   " ("
>   date
> @@ -733,7 +740,8 @@ current buffer, if possible."
>  (setq content-end (point-marker))
>  
>  ;; Indent according to the depth in the thread.
> -(indent-rigidly content-start content-end depth)
> +(when notmuch-show-indent-messages-in-thread
> +  (indent-rigidly content-start content-end depth))

Not a big deal, but I would prefer `if' instead of `when' here.

Regards,
  Dmitry

>  
>  (setq message-end (point-max-marker))
>  
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] Emacs: Add variable to toggle message indentation in a thread

[Daniel Schoepe]

Hi Felix,

On Mon, 11 Jul 2011 10:42:04 +0200, Felix Geller  wrote:
> +(defcustom notmuch-show-indent-messages-in-thread nil
> +  "Should the messages in a thread be indented according to their respective 
> depth in the thread?"
> +  :group 'notmuch
> +  :type 'boolean)
> +

I think this should default to t, so it doesn't change the current
default behavior (which I find quite helpful).

Cheers,
Daniel
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110711/093d09f2/attachment.pgp>

[PATCH] Emacs: Add variable to toggle message indentation in a thread

[Felix Geller]

Hi Dmitry,

thank you for the comments. I included an updated patch that also
includes Daniel's comment regarding the default value. 

I didn't change the "when" though--not because of personal reasons
;)--but because it is used for determining indentation of multi-parts.


Cheers,
Felix



On Mon, 11 Jul 2011 12:53:04 +0400, Dmitry Kurochkin  wrote:
> Hi Felix.
> 
> On Mon, 11 Jul 2011 10:42:04 +0200, Felix Geller  wrote:
> > Hi,
> > 
> > I added a variable to toggle message indentation in Emacs.
> > 
> > Please let me know what you think.
> > 
> 
> I like the change.  Though I do not think I would use it without
> chronological sorting.
> 
> Comments on the code below.
> 
> Regards,
>   Dmitry
> 
> > 
> > Cheers,
> > Felix
> > 
> > 
> > diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
> > index a433dec..8101c27 100644
> > --- a/emacs/notmuch-show.el
> > +++ b/emacs/notmuch-show.el
> > @@ -90,6 +90,11 @@ any given message."
> >:group 'notmuch
> >:type 'boolean)
> >  
> > +(defcustom notmuch-show-indent-messages-in-thread nil
> > +  "Should the messages in a thread be indented according to their 
> > respective depth in the thread?"
> 
> This line is too long and should be split.
> 
> > +  :group 'notmuch
> > +  :type 'boolean)
> > +
> >  (defcustom notmuch-show-indent-multipart nil
> >"Should the sub-parts of a multipart/* part be indented?"
> >;; dme: Not sure which is a good default.
> > @@ -237,7 +242,9 @@ unchanged ADDRESS if parsing fails."
> >"Insert a notmuch style headerline based on HEADERS for a
> >  message at DEPTH in the current thread."
> >(let ((start (point)))
> > -(insert (notmuch-show-spaces-n depth)
> > +(insert (if notmuch-show-indent-messages-in-thread
> > +   (notmuch-show-spaces-n depth)
> > + "")
> 
> (if notmuch-show-indent-messages-in-thread
> (insert (notmuch-show-spaces-n depth)))
> 
> Is cleaner and avoids useless empty string insert.
> 
> > (notmuch-show-clean-address (plist-get headers :From))
> > " ("
> > date
> > @@ -733,7 +740,8 @@ current buffer, if possible."
> >  (setq content-end (point-marker))
> >  
> >  ;; Indent according to the depth in the thread.
> > -(indent-rigidly content-start content-end depth)
> > +(when notmuch-show-indent-messages-in-thread
> > +  (indent-rigidly content-start content-end depth))
> 
> Not a big deal, but I would prefer `if' instead of `when' here.
> 
> Regards,
>   Dmitry
> 
> >  
> >  (setq message-end (point-max-marker))
> >  
> > ___
> > notmuch mailing list
> > notmuch at notmuchmail.org
> > http://notmuchmail.org/mailman/listinfo/notmuch


commit f90fafdc0545a825ea4b69db5e51c2e866a4ff5e
Author: Felix Geller 
Date:   Mon Jul 11 10:39:00 2011 +0200

Added a variable to toggle message indentation for thread view in emacs.
 - includes adjustments according to comments from ML

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index a433dec..1834066 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -90,6 +90,11 @@ any given message."
   :group 'notmuch
   :type 'boolean)

+(defcustom notmuch-show-indent-messages-in-thread t
+  "Should messages be indented according to their depth in a thread?"
+  :group 'notmuch
+  :type 'boolean)
+
 (defcustom notmuch-show-indent-multipart nil
   "Should the sub-parts of a multipart/* part be indented?"
   ;; dme: Not sure which is a good default.
@@ -237,8 +242,9 @@ unchanged ADDRESS if parsing fails."
   "Insert a notmuch style headerline based on HEADERS for a
 message at DEPTH in the current thread."
   (let ((start (point)))
-(insert (notmuch-show-spaces-n depth)
-   (notmuch-show-clean-address (plist-get headers :From))
+(when notmuch-show-indent-messages-in-thread
+  (insert (notmuch-show-spaces-n depth)))
+(insert (notmuch-show-clean-address (plist-get headers :From))
" ("
date
    ") ("
@@ -733,7 +739,8 @@ current buffer, if possible."
 (setq content-end (point-marker))

 ;; Indent according to the depth in the thread.
-(indent-rigidly content-start content-end depth)
+(when notmuch-show-indent-messages-in-thread
+  (indent-rigidly content-start content-end depth))

 (setq message-end (point-max-marker))

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

[python] querystrings as unicode literals?

[Sebastian Spaeth]

On Thu, 7 Jul 2011 12:37:00 +0100, Patrick Totzke  wrote:
> Hi!
> Something strange goes on when I use unicode literals as querystrings:
> Database().create_query(u'teststring') yields different results than
> Database().create_query('teststring')..
> 
> Now it should not be a problem to decode the string to whatever encoding
> is used by notmuch/xapian internally using 'teststring'.encode('utf8')
> for example. But can I reliably expect all strings in the index to be valid 
> utf8?
> 
> At any rate, I think this conversion should be made from inside the bindings.
> A query should return the same results for querystrings as string- and 
> unicode literals. 
> Any thoughts?

I hate encodings and they always confuse the heck out of me. I would
prefer if everything was always UTF8. notmuch.h actually doesn't state
which encoding the query string should be and neither did
http://xapian.org/docs/queryparser.html. ojwb said, it takes UTF-8, so
that's what we should be doing.

I'll send a patch as a reply shortly, Patrick, do you care to test if
this fixes things for you?

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110711/894c58b8/attachment.pgp>

[PATCH] python: Encode query string as a utf-8 byte array

[Sebastian Spaeth]

If we pass in an unicode instance as query string, we would probably get
weird behavior (and indeed do so, see mail
id:"20110707113700.GA16347 at megatron"). If a unicode instance is passed
in, make sure we encode it properly to an utf-8 encoded byte string.

Signed-off-by: Sebastian Spaeth 
---
Patrick, can you test, if this fixes the inconsistent behavior in a good way?

 bindings/python/notmuch/database.py |8 +---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/bindings/python/notmuch/database.py 
b/bindings/python/notmuch/database.py
index 3770b13..859fb18 100644
--- a/bindings/python/notmuch/database.py
+++ b/bindings/python/notmuch/database.py
@@ -501,7 +501,7 @@ class Query(object):
 :param db: An open database which we derive the Query from.
 :type db: :class:`Database`
 :param querystr: The query string for the message.
-:type querystr: str
+:type querystr: utf-8 encoded str or unicode
 """
 self._db = None
 self._query = None
@@ -517,7 +517,7 @@ class Query(object):
 :param db: Database to create the query from.
 :type db: :class:`Database`
 :param querystr: The query string
-:type querystr: str
+:type querystr: utf-8 encoded str or unicode
 :returns: Nothing
 :exception: :exc:`NotmuchError`

@@ -529,7 +529,9 @@ class Query(object):
 raise NotmuchError(STATUS.NOT_INITIALIZED)
 # create reference to parent db to keep it alive
 self._db = db
-
+if is_instance(querystr, unicode):
+# xapian takes utf-8 encoded byte arrays
+querystr = querystr.encode('utf-8')
 # create query, return None if too little mem available
 query_p = Query._create(db.db_p, querystr)
 if query_p is None:
-- 
1.7.4.1

[PATCH v2] python: Encode query string as a utf-8 byte array

[Sebastian Spaeth]

If we pass in an unicode instance as query string, we would probably get
weird behavior (and indeed do so, see mail
id:"20110707113700.GA16347 at megatron"). If a unicode instance is passed
in, make sure we encode it properly to an utf-8 encoded byte string.

Signed-off-by: Sebastian Spaeth 
---
DOH, I should test my patches for typos before actually sending them off. This 
one should be fine.

 bindings/python/notmuch/database.py |8 +---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/bindings/python/notmuch/database.py 
b/bindings/python/notmuch/database.py
index 3770b13..84cf79b 100644
--- a/bindings/python/notmuch/database.py
+++ b/bindings/python/notmuch/database.py
@@ -501,7 +501,7 @@ class Query(object):
 :param db: An open database which we derive the Query from.
 :type db: :class:`Database`
 :param querystr: The query string for the message.
-:type querystr: str
+:type querystr: utf-8 encoded str or unicode
 """
 self._db = None
 self._query = None
@@ -517,7 +517,7 @@ class Query(object):
 :param db: Database to create the query from.
 :type db: :class:`Database`
 :param querystr: The query string
-:type querystr: str
+:type querystr: utf-8 encoded str or unicode
 :returns: Nothing
 :exception: :exc:`NotmuchError`

@@ -529,7 +529,9 @@ class Query(object):
 raise NotmuchError(STATUS.NOT_INITIALIZED)
 # create reference to parent db to keep it alive
 self._db = db
-
+if isinstance(querystr, unicode):
+# xapian takes utf-8 encoded byte arrays
+querystr = querystr.encode('utf-8')
 # create query, return None if too little mem available
 query_p = Query._create(db.db_p, querystr)
 if query_p is None:
-- 
1.7.4.1

[PATCH] Emacs: Add variable to toggle message indentation in a thread

[Dmitry Kurochkin]

On Mon, 11 Jul 2011 11:24:57 +0200, Felix Geller  wrote:
> Hi Dmitry,
> 
> thank you for the comments. I included an updated patch that also
> includes Daniel's comment regarding the default value. 
> 

Another thing that would be nice to have is a test for this feature.

Regards,
  Dmitry

> I didn't change the "when" though--not because of personal reasons
> ;)--but because it is used for determining indentation of multi-parts.
> 
> 
> Cheers,
> Felix
> 
> 
> 
> On Mon, 11 Jul 2011 12:53:04 +0400, Dmitry Kurochkin  gmail.com> wrote:
> > Hi Felix.
> > 
> > On Mon, 11 Jul 2011 10:42:04 +0200, Felix Geller  
> > wrote:
> > > Hi,
> > > 
> > > I added a variable to toggle message indentation in Emacs.
> > > 
> > > Please let me know what you think.
> > > 
> > 
> > I like the change.  Though I do not think I would use it without
> > chronological sorting.
> > 
> > Comments on the code below.
> > 
> > Regards,
> >   Dmitry
> > 
> > > 
> > > Cheers,
> > > Felix
> > > 
> > > 
> > > diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
> > > index a433dec..8101c27 100644
> > > --- a/emacs/notmuch-show.el
> > > +++ b/emacs/notmuch-show.el
> > > @@ -90,6 +90,11 @@ any given message."
> > >:group 'notmuch
> > >:type 'boolean)
> > >  
> > > +(defcustom notmuch-show-indent-messages-in-thread nil
> > > +  "Should the messages in a thread be indented according to their 
> > > respective depth in the thread?"
> > 
> > This line is too long and should be split.
> > 
> > > +  :group 'notmuch
> > > +  :type 'boolean)
> > > +
> > >  (defcustom notmuch-show-indent-multipart nil
> > >"Should the sub-parts of a multipart/* part be indented?"
> > >;; dme: Not sure which is a good default.
> > > @@ -237,7 +242,9 @@ unchanged ADDRESS if parsing fails."
> > >"Insert a notmuch style headerline based on HEADERS for a
> > >  message at DEPTH in the current thread."
> > >(let ((start (point)))
> > > -(insert (notmuch-show-spaces-n depth)
> > > +(insert (if notmuch-show-indent-messages-in-thread
> > > + (notmuch-show-spaces-n depth)
> > > +   "")
> > 
> > (if notmuch-show-indent-messages-in-thread
> > (insert (notmuch-show-spaces-n depth)))
> > 
> > Is cleaner and avoids useless empty string insert.
> > 
> > >   (notmuch-show-clean-address (plist-get headers :From))
> > >   " ("
> > >   date
> > > @@ -733,7 +740,8 @@ current buffer, if possible."
> > >  (setq content-end (point-marker))
> > >  
> > >  ;; Indent according to the depth in the thread.
> > > -(indent-rigidly content-start content-end depth)
> > > +(when notmuch-show-indent-messages-in-thread
> > > +  (indent-rigidly content-start content-end depth))
> > 
> > Not a big deal, but I would prefer `if' instead of `when' here.
> > 
> > Regards,
> >   Dmitry
> > 
> > >  
> > >  (setq message-end (point-max-marker))
> > >  
> > > ___
> > > notmuch mailing list
> > > notmuch at notmuchmail.org
> > > http://notmuchmail.org/mailman/listinfo/notmuch
> 
> 
> commit f90fafdc0545a825ea4b69db5e51c2e866a4ff5e
> Author: Felix Geller 
> Date:   Mon Jul 11 10:39:00 2011 +0200
> 
> Added a variable to toggle message indentation for thread view in emacs.
>  - includes adjustments according to comments from ML
> 
> diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
> index a433dec..1834066 100644
> --- a/emacs/notmuch-show.el
> +++ b/emacs/notmuch-show.el
> @@ -90,6 +90,11 @@ any given message."
>:group 'notmuch
>:type 'boolean)
>  
> +(defcustom notmuch-show-indent-messages-in-thread t
> +  "Should messages be indented according to their depth in a thread?"
> +  :group 'notmuch
> +  :type 'boolean)
> +
>  (defcustom notmuch-show-indent-multipart nil
>"Should the sub-parts of a multipart/* part be indented?"
>;; dme: Not sure which is a good default.
> @@ -237,8 +242,9 @@ unchanged ADDRESS if parsing fails."
>"Insert a notmuch style headerline based on HEADERS for a
>  message at DEPTH in the current thread."
>(let ((start (point)))
> -(insert (notmuch-show-spaces-n depth)
> - (notmuch-show-clean-address (plist-get headers :From))
> +(when notmuch-show-indent-messages-in-thread
> +  (insert (notmuch-show-spaces-n depth)))
> +(insert (notmuch-show-clean-address (plist-get headers :From))
>   " ("
>   date
>   ") ("
> @@ -733,7 +739,8 @@ current buffer, if possible."
>  (setq content-end (point-marker))
>  
>  ;; Indent according to the depth in the thread.
> -(indent-rigidly content-start content-end depth)
> +(when notmuch-show-indent-messages-in-thread
> +  (indent-rigidly content-start content-end depth))
>  
>  (setq message-end (point-max-marker))
>  

[PATCH] Emacs: Add variable to toggle message indentation in a thread

[Felix Geller]

emacs/notmuch-show.el
> > +++ b/emacs/notmuch-show.el
> > @@ -90,6 +90,11 @@ any given message."
> >:group 'notmuch
> >:type 'boolean)
> >  
> > +(defcustom notmuch-show-indent-messages-in-thread t
> > +  "Should messages be indented according to their depth in a thread?"
> > +  :group 'notmuch
> > +  :type 'boolean)
> > +
> >  (defcustom notmuch-show-indent-multipart nil
> >"Should the sub-parts of a multipart/* part be indented?"
> >;; dme: Not sure which is a good default.
> > @@ -237,8 +242,9 @@ unchanged ADDRESS if parsing fails."
> >"Insert a notmuch style headerline based on HEADERS for a
> >  message at DEPTH in the current thread."
> >(let ((start (point)))
> > -(insert (notmuch-show-spaces-n depth)
> > -   (notmuch-show-clean-address (plist-get headers :From))
> > +(when notmuch-show-indent-messages-in-thread
> > +  (insert (notmuch-show-spaces-n depth)))
> > +(insert (notmuch-show-clean-address (plist-get headers :From))
> > " ("
> > date
> > ") ("
> > @@ -733,7 +739,8 @@ current buffer, if possible."
> >  (setq content-end (point-marker))
> >  
> >  ;; Indent according to the depth in the thread.
> > -(indent-rigidly content-start content-end depth)
> > +(when notmuch-show-indent-messages-in-thread
> > +  (indent-rigidly content-start content-end depth))
> >  
> >  (setq message-end (point-max-marker))
> >  
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 202 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110711/2f498710/attachment.pgp>

[PATCH] emacs: NEWS entry for user-defined sections

[Daniel Schoepe]

---
 NEWS |   13 +
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/NEWS b/NEWS
index f3fefad..98a6b28 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,16 @@
+Notmuch 0.7 (-MM-DD)
+===
+New emacs-interface features
+
+Customizable notmuch-hello page
+
+  The notmuch-hello page can now be customized using the
+  notmuch-hello-sections variable. It allows removing and adding
+  arbitrary sections (functions that insert UI elements).  Various
+  often-used, configurable section types are also provided. This
+  feature is also fully usable via the customize-interface. For more
+  information, see `M-x describe-variable notmuch-hello-sections'.
+
 Notmuch 0.6 (2011-07-01)
 ===
 New, general features
-- 
1.7.5.4

notmuch Digest, Vol 20, Issue 57

[Sebastian Spaeth]

On Wed, 06 Jul 2011 20:46:48 +0200, Daniel Schoepe  wrote:
> One problem is that maildir doesn't support tags, so we would have to
> switch to a format that does or somehow store them in the maildir, in
> which case we would also have to adapt offlineimap or a similar tool to
> sync tags as well.

Right, Maildirs don't store them. AFAIK dovecot stores them in the
user-defined 'use-1-letter-abbrev-for-up-to-20-tags' notation or similar
for it's maildir. But there is no standard, and maildir is not the
answer. Either notmuch would have to directly interact via IMAP protocol
(outch), or some intermediary fetcher would have to store tags in some
type of database (which is what offlineimap could do at some point in
time).

> > Do you know what the status is of *server* support ? Because imo this *is* a
> > big deal, without real standardized server support an IMAP store for tags is
> > off the table.
> 
> Support for tags is mentioned in the RFC for IMAP, but it's optional. As
> far as I know, must servers today support them though.

I can't speak for Gmail, but all major servers, ie Cyrus, Dovecot, and
even Exchange seem to handle tags just fine.

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110711/8ad36281/attachment.pgp>

notmuch Digest, Vol 20, Issue 57

[Daniel Schoepe]

On Mon, 11 Jul 2011 15:22:24 +0200, Sebastian Spaeth  
wrote:
> > Support for tags is mentioned in the RFC for IMAP, but it's optional. As
> > far as I know, must servers today support them though.
> 
> I can't speak for Gmail, but all major servers, ie Cyrus, Dovecot, and
> even Exchange seem to handle tags just fine.

I just realized that this was a quite misleading typo, that should have
read "As far as I know, _most_ servers today support them though". 

I'd be very suprised if Gmail didn't support them. And even if not, one
could work around that by having a hypothetical tag synchroniser handle
Gmail differently and use their tagging mechanism:

http://code.google.com/apis/gmail/imap/#x-gm-labels

This would also have the added benefit of notmuch tags showing up in the
other gmail-tag-aware applications, like the web-interface.

Another issue brought up by DraX on IRC is that IMAP keywords don't
handle unicode. (Although the RFC specifies that every character except
some excluded special characters are allowed, so I guess it's
implementation-dependent).

I think the best way to go would be to extend both maildir and
offlineimap somehow to store tags and then store them as IMAP keywords /
gmail-labels in the case of Gmail on the server.

Cheers,
Daniel
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110711/897a55e0/attachment.pgp>

Encodings

[Sebastian Spaeth]

Hi all,
after I was notified about how notmuch's python bindings perform
differently depending on whether we hand it (byte-based) ASCII strings
or unicode, I tried to disentangle what encodings to expect and send it
to. The answer is that things are very implicit. notmuch.h speaks of
strings but never mentions encodings, xapian docs don't mention
encodings but ojwb confirmed that it expects utf-8.

So, can be document what encoding we are expected to pass in the various
APIs and where we can guarantee to actually return UTF-8 encoded
strings? For some of the stuff we read directly from the files, eg
arbitrary headers, we can probably be least sure, but are e.g. the
returned tags always utf-8?

I would love to make the python bindings use unicode() instances in
cases where we can be sure to actually receive utf-8 encoded strings.

Encodings make my brain hurt. Unfortunately one cannot simply ignore
them.

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110711/0c5a127e/attachment.pgp>

[PATCH 0/2] lib: Don't always move from maildir new/ to maildir cur/

[Louis Rilling]

Hello,

Here is an alternative, as we discussed earlier. This is enough to keep me
using mutt's ability to show the "new" status, and to allow me to test notmuch
with my real emails. Altough my notmuch config uses

[new]
tags=new;

[maildir]
synchronize_flags=true

messages will be kept in "new/", even with

[new]
tags=inbox;unread;

[maildir]
synchronize_flags=true

as long as no maildir flags have to be changed.

The first patch can be applied independently.

Thanks,

Louis


Louis Rilling (2):
  tags_to_maildir_flags: Cleanup double assignement
  tags_to_maildir_flags: Don't rename if no flags change

 lib/message.cc |   14 +++---
 1 files changed, 11 insertions(+), 3 deletions(-)

-- 
1.7.2.5

[PATCH 1/2] tags_to_maildir_flags: Cleanup double assignement

[Louis Rilling]

The for loop right after already does the job.

Signed-off-by: Louis Rilling 
---
 lib/message.cc |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/lib/message.cc b/lib/message.cc
index d993cde..64b6cf8 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -1172,8 +1172,6 @@ _new_maildir_filename (void *ctx,
 if (info == NULL) {
info = filename + strlen(filename);
 } else {
-   flags = info + 3;
-
/* Loop through existing flags in filename. */
for (flags = info + 3, last_flag = 0;
 *flags;
-- 
1.7.2.5

[PATCH 2/2] tags_to_maildir_flags: Don't rename if no flags change

[Louis Rilling]

notmuch_message_tags_to_maildir_flags() unconditionally moves messages from
maildir directory "new/" to maildir directory "cur/", which makes messages lose
their "new" status in the MUA. However some users want to keep this "new"
status after, for instance, an auto-tagging of new messages.

However, as Austin mentioned and according to the maildir specification,
messages living in "new/" are not allowed to have flags, even if mutt allows it
to happen. For this reason, this patch prevents moving messages from "new/" to
"cur/", only if no flags have to be changed. It's hopefully enough to satisfy
mutt (and maybe other MUAs showing the "new" status) users checking the "new"
status.

Signed-off-by: Louis Rilling 
---
 lib/message.cc |   12 +++-
 1 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/lib/message.cc b/lib/message.cc
index 64b6cf8..131d99b 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -1139,7 +1139,7 @@ _get_maildir_flag_actions (notmuch_message_t *message,
  * compute the new maildir filename.
  *
  * If the existing filename is in the directory "new", the new
- * filename will be in the directory "cur".
+ * filename will be in the directory "cur", unless no flags are changed.
  *
  * After a sequence of ":2," in the filename, any subsequent
  * single-character flags will be added or removed according to the
@@ -1162,6 +1162,7 @@ _new_maildir_filename (void *ctx,
 char *filename_new, *dir;
 char flag_map[128];
 int flags_in_map = 0;
+bool flags_changed = false;
 unsigned int i;
 char *s;

@@ -1202,6 +1203,7 @@ _new_maildir_filename (void *ctx,
if (flag_map[flag] == 0) {
flag_map[flag] = 1;
flags_in_map++;
+   flags_changed = true;
}
 }

@@ -1210,9 +1212,17 @@ _new_maildir_filename (void *ctx,
if (flag_map[flag]) {
flag_map[flag] = 0;
flags_in_map--;
+   flags_changed = true;
}
 }

+/* No need to rename. Messages in new/ can be kept in new/.
+ * Note: We don't even try to fix buggy messages having flags and living in
+ * new/. It's not our business.
+ */
+if (!flags_changed)
+   return NULL;
+
 filename_new = (char *) talloc_size (ctx,
 info - filename +
 strlen (":2,") + flags_in_map + 1);
-- 
1.7.2.5

Encodings

[Carl Worth]

On Mon, 11 Jul 2011 16:04:17 +0200, Sebastian Spaeth  
wrote:
> The answer is that things are very implicit. notmuch.h speaks of
> strings but never mentions encodings

Much of this was intentional on my part.

For example, I intentionally avoided restrictions on what could be
stored as a tag in the database, (other than the terminating character
implied by "string" of course).

> So, can be document what encoding we are expected to pass in the various
> APIs

Yes, let's clarify documentation wherever we need to.

> For some of the stuff we read directly from the files, eg
> arbitrary headers, we can probably be least sure

The headers should be decoded to utf-8, (via
g_mime_utils_header_decode_text), before being stored in the database.

> but are e.g. the returned tags always utf-8?

No. The tag data is returned exactly as the user presented it.

> I would love to make the python bindings use unicode() instances in
> cases where we can be sure to actually receive utf-8 encoded strings.
> 
> Encodings make my brain hurt. Unfortunately one cannot simply ignore
> them.

I think a lot of the pain here is due to some bad design decisions in
python itself. Of course, my saying that doesn't make things any easier
for you.

But do tell me what more we can do to clarify behavior or documentation.

-Carl

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

[PATCH] Emacs: Add variable to toggle message indentation in a thread

[Jameson Graef Rollins]

On Mon, 11 Jul 2011 10:42:04 +0200, Felix Geller  wrote:
> I added a variable to toggle message indentation in Emacs.

Hi, Felix.  Thanks for submitting this patch.  I think it's a good idea.
I have a couple of comments below, a couple of which echo what Dmitry
has already pointed out.

> diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el

This patch doesn't include a commit log, which is something we generally
require.  The preferred way to send patches is with git format-patch or
send-email, both of which format patches in such a way that they can be
immediately applied to a git repo, including with the commit log.

> +(defcustom notmuch-show-indent-messages-in-thread nil
> +  "Should the messages in a thread be indented according to their respective 
> depth in the thread?"
> +  :group 'notmuch
> +  :type 'boolean)

I agres with Dmitry that this should default to 't', to be consistent
with the current default behavior.

> -(insert (notmuch-show-spaces-n depth)
> +(insert (if notmuch-show-indent-messages-in-thread
> + (notmuch-show-spaces-n depth)
> +   "")

I also agree with Dmitry's suggestion here to use the following slightly
simpler construct:

 (if notmuch-show-indent-messages-in-thread
 (insert (notmuch-show-spaces-n depth)))

Finally, as Dmitry also points out, you'll almost certainly need to
construct a test for this feature, since it constitutes a pretty big
formatting change.  It should probably test for both cases of the
customization variable.  Check out the tests in tests/emacs for
guidance.

hth.

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

[PATCH] Feature request: nicknames for senders

[Jason Woofenden]

I implemented a feature I wanted: nicknames for the list of senders
on the search view.

At first I just added a setting with my full name and had it
replace that with "me". But then I figured it'd be better to allow
the user to specify a list of replacements, and instead made a more
general "nicknames" list.

Then I made myself a nice long dictionary to shorten the names of
folks I communicate with regularly. Mostly reducing them to first
names. Now it's much more common that I can see all the senders in
the narrow senders column.


Thoughts?


   -- Jason

[PATCH] vim: add setting to shorten/fix sender names

[Jason Woofenden]

Add a new setting: g:notmuch_nicknames (dictionary)

When reformatting the list of senders in the search view, replace any names
matching keys in g:notmuch_nicknames with the corresponding values.
---
 vim/plugin/notmuch.vim |   19 ++-
 1 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/vim/plugin/notmuch.vim b/vim/plugin/notmuch.vim
index 12a0f88..5debaf6 100644
--- a/vim/plugin/notmuch.vim
+++ b/vim/plugin/notmuch.vim
@@ -103,6 +103,10 @@ let s:notmuch_compose_headers_defaults = [
 \ 'Subject'
 \ ]

+" To shorten/change the sender names in the search views:
+" let g:notmuch_nicknames = {'John Smith': 'me', 'Jane Smith': 'Jane'}
+
+
 " --- keyboard mapping definitions {{{1

 " --- --- bindings for folders mode {{{2
@@ -267,7 +271,20 @@ function! s:NM_cmd_search_fmtline(line)
 let p = split(at, '[@.]')
 let flist[p[0]] = 1
 endfor
-let from = join(keys(flist), ", ")
+if exists('g:notmuch_nicknames')
+let from_fixed = []
+for at in keys(flist)
+if has_key(g:notmuch_nicknames, at)
+call add(from_fixed, g:notmuch_nicknames[at])
+else
+call add(from_fixed, at)
+endif
+endfor
+let from = join(from_fixed, ', ')
+else
+let from = join(keys(flist), ', ')
+endif
+
 return printf("%-12s %3s %-20.20s | %s (%s)", m[2], m[3], from, m[5], 
m[6])
 endfunction

-- 
1.7.5.4

Slowness (search opens every email file?)

[Jason Woofenden]

Hi all,

I'm having a great time patching up the vim frontend, but I've got
an issue that is in the backend, and seems far above my head at
this point:

notmuch search tag:foo is slow!

(when my e-mail files are not already in the disk cache)

I saw on my activity monitor applet that it was using mostly i/o,
and started to wonder if it was opening every e-mail. I little work
with strace and searching revealed that this command was opening
many many e-mail files from my maildir(s). I spent a little while
digging around in the notmuch source, and didn't see where it was
opening the email files.

I don't think the search command should be opening the files. So my
questions:

1) Why is it opening the e-mail files? What information is being
read?

2) Do you agree that it should instead get this information from
the database?

3) How hard would it be make this fast? What would it take?

4) Who wants to do it?


I'd like it to be able to spit out 1000 threads in under a second.
Preferably under 100ms.


Thank you,-- Jason


P.S. I mean really slow... 

notmuch search tag:foo  took  0.5 seconds for 32 threads

notmuch search foo took 6.4 seconds for 130 threads

Everything's getting into my cache, so I can't easily get lots of
numbers. For a while I had a simple search (tag:foo and tag:bar)
which returned about 600 threads, and it would frequently take
seconds.

problems with symbol hiding on Debian Squeeze i386

[David Bremner]

Julien Valroth reported on IRC that he had problems with the initial
call of 'notmuch new' crashing with

terminate called after throwing an instance of 'Xapian::InvalidArgumentError'

I confirmed that the following quick and dirty patch seems to fix the problem.

--- a/lib/Makefile.local
+++ b/lib/Makefile.local
@@ -36,7 +36,7 @@ LIBRARY_SUFFIX = so
 LINKER_NAME = libnotmuch.$(LIBRARY_SUFFIX)
 SONAME = $(LINKER_NAME).$(LIBNOTMUCH_VERSION_MAJOR)
 LIBNAME = $(SONAME).$(LIBNOTMUCH_VERSION_MINOR).$(LIBNOTMUCH_VERSION_RELEASE)
-LIBRARY_LINK_FLAG = -shared -Wl,--version-script=notmuch.sym,-soname=$(SONAME)
+LIBRARY_LINK_FLAG = -shared -Wl,-soname=$(SONAME)
 ifeq ($(LIBDIR_IN_LDCONFIG),1)
 ifeq ($(DESTDIR),)
 LIBRARY_INSTALL_POST_COMMAND=ldconfig

I haven't quite decided what to do about this yet, but I thought I'd get
this on the record, because it seems to me a few people have been having
problems with this.

FWIW, I tested with various versions of xapian and libgmime, but the
problem still exists for  gmime 2.4.25-1, and xapian 1.2.5-1, both
recompiled for squeeze.

If you install the libxapian22 from sid, then gcc and libc6 are both
upgraded, and the problem goes away (but you are not really running
squeeze anymore).  

About the only good news is that the symbol hiding test does indeed fail
on squeeze i386.

I have appended part of the backtrace, in case anyone finds it
illuminating.  As far as I can tell without line numbers, the catch in
_notmuch_message_remove_term is failing. I suppose this could be the
kind of "exceptions start mysteriously malfunctioning" that
http://gcc.gnu.org/wiki/Visibility warns about.

Xapian _seems_ to do the right thing with visisibility
declarations for these exception classes.

I don't know what, if anything to conclude from the fact that everything
seems to work fine in gcc 4.6.

backtrace:

#4  0xf7ac2442 in std::terminate() () from /usr/lib/libstdc++.so.6
#5  0xf7ac2581 in __cxa_throw () from /usr/lib/libstdc++.so.6
#6  0xf7b3fb83 in Xapian::Document::Internal::remove_term(std::string const&) ()
   from /usr/lib/sse2/libxapian.so.22
#7  0xf7b3fc76 in Xapian::Document::remove_term(std::string const&) ()
   from /usr/lib/sse2/libxapian.so.22
#8  0xf7fd5233 in _notmuch_message_remove_term ()
   from /home/bremner/software/upstream/notmuch/lib/libnotmuch.so.1
#9  0xf7fd5389 in notmuch_message_remove_tag ()
   from /home/bremner/software/upstream/notmuch/lib/libnotmuch.so.1
#10 0xf7fd63ea in notmuch_message_maildir_flags_to_tags ()
   from /home/bremner/software/upstream/notmuch/lib/libnotmuch.so.1
#11 0x08050483 in add_files_recursive ()
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 315 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110711/7b9a1fe2/attachment.pgp>

[PATCH 2/2] tags_to_maildir_flags: Don't rename if no flags change

[Austin Clements]

I worry that this may compound the confusion caused by mutt's handling
of the new flag, but I suppose people aren't likely to manipulate any
of the other maildir-synchronized flags without also marking the
message as seen.  At any rate, the change is certainly correct
technically.  A few nits below.

Quoth Louis Rilling on Jul 11 at  4:36 pm:
> notmuch_message_tags_to_maildir_flags() unconditionally moves messages from
> maildir directory "new/" to maildir directory "cur/", which makes messages 
> lose
> their "new" status in the MUA. However some users want to keep this "new"
> status after, for instance, an auto-tagging of new messages.
> 
> However, as Austin mentioned and according to the maildir specification,
> messages living in "new/" are not allowed to have flags, even if mutt allows 
> it
> to happen. For this reason, this patch prevents moving messages from "new/" to
> "cur/", only if no flags have to be changed. It's hopefully enough to satisfy
> mutt (and maybe other MUAs showing the "new" status) users checking the "new"
> status.
> 
> Signed-off-by: Louis Rilling 
> ---
>  lib/message.cc |   12 +++-
>  1 files changed, 11 insertions(+), 1 deletions(-)
> 
> diff --git a/lib/message.cc b/lib/message.cc
> index 64b6cf8..131d99b 100644
> --- a/lib/message.cc
> +++ b/lib/message.cc
> @@ -1139,7 +1139,7 @@ _get_maildir_flag_actions (notmuch_message_t *message,
>   * compute the new maildir filename.
>   *
>   * If the existing filename is in the directory "new", the new
> - * filename will be in the directory "cur".
> + * filename will be in the directory "cur", unless no flags are changed.
>   *
>   * After a sequence of ":2," in the filename, any subsequent
>   * single-character flags will be added or removed according to the
> @@ -1162,6 +1162,7 @@ _new_maildir_filename (void *ctx,
>  char *filename_new, *dir;
>  char flag_map[128];
>  int flags_in_map = 0;
> +bool flags_changed = false;

The convention in notmuch is to use notmuch_bool_t, TRUE, and FALSE
(though, admittedly, I don't know why; avoiding C99-isms?)

>  unsigned int i;
>  char *s;
>  
> @@ -1202,6 +1203,7 @@ _new_maildir_filename (void *ctx,
>   if (flag_map[flag] == 0) {
>   flag_map[flag] = 1;
>   flags_in_map++;
> + flags_changed = true;
>   }
>  }
>  
> @@ -1210,9 +1212,17 @@ _new_maildir_filename (void *ctx,
>   if (flag_map[flag]) {
>   flag_map[flag] = 0;
>   flags_in_map--;
> + flags_changed = true;
>   }
>  }
>  
> +/* No need to rename. Messages in new/ can be kept in new/.
> + * Note: We don't even try to fix buggy messages having flags and living 
> in
> + * new/. It's not our business.
> + */
> +if (!flags_changed)
> + return NULL;
> +

NULL generally indicates an error in notmuch and is currently used
that way in _new_maildir_filename, so even though the caller currently
doesn't really care, I'd lean against overloading it to indicate that
the filename doesn't need to change.  Despite the slight inefficiency,
I would recommend returning talloc_strdup (ctx, filename).

>  filename_new = (char *) talloc_size (ctx,
>info - filename +
>strlen (":2,") + flags_in_map + 1);

[PATCH v2] emacs: bad regexp @ `notmuch-search-process-filter'

[Pieter Praet]

TL;DR: I can haz regex pl0x?


I've updated the regex a bit to prevent it from choking on the whole
"parens in subject vs. parens around tags vs. parens around matching
Message-Id's" deal, but it still causes errors in the search buffer due
to the list of Message-Id's being cut off at a seemingly arbitrary point,
and this for *different* results on pretty much every refresh.

All tests pass, except for the ones I've mentioned before [1] (which
don't test anything tagging-related, just `notmuch-show'), though even
those fail to fail consistently :<. This variability can't be related to
residual files, as I always run the test suite like this:

  rm -rf /dev/shm/notmuch/* && make test OPTIONS="--root=/dev/shm/notmuch"


So, to keep this on track for 0.7 whilst keeping myself from having to
send spammerific amounts of patches, I've squashed the whole deal in
this single patch. Don't worry though, it's all quite grokkable:


notmuch-search.c

- Make `notmuch search' *only* append results with their Message-Id's
  when supplied with the "--output=summary-ids" option, to prevent a
  slew of failing tests obscuring the relevant ones.


emacs/notmuch.el

- Make `notmuch-search' run the notmuch binary with the "--output=summary-ids"
  option, to receive search results appended with their lists of Message-Id's.

- Update the regex @ `notmuch-search-process-filter' to include a new atom,
  which matches the list of Message-Id's at the end of every search result
  returned by the notmuch binary.
  To each individual result in the search buffer, this matched string is
  added as a text property called `notmuch-search-msgids'.

- Add 2 functions to return the `notmuch-search-msgids' property of search
  results: `notmuch-search-find-msgids', `notmuch-search-find-msgids-region'.

- Add a function to stash the Message-Id's of (a region of) search results:
  `notmuch-search-stash-msgids', bound to "m" in `notmuch-search-stash-map'.
  Mainly for testing purposes.

- Merge `notmuch-call-notmuch-process' into `notmuch-tag':
  `notmuch-tag' was the only thing making use of `notmuch-call-notmuch-process',
  and the extra layer of abstraction would complicate making `notmuch-tag' send
  arguments on stdin (see next point).

- Make `notmuch-tag' send its query string on stdin:
  Instead of providing the query string as a (potentially very long) command
  line argument, `notmuch-tag' now dumps it into a temporary buffer, which
  `call-process-region' sends to `notmuch-command' on stdin.
  This is needed to circumvent "$command: arg list too long" errors due
  to command line argument length limitations imposed by the kernel (ARG_MAX).

- Fix the actual bug(s) this patch series is intended to address by making
  the tagging functions procure their targets from the `notmuch-search-msgids'
  property with `notmuch-search-find-msgids-region', instead of using x:
  - `notmuch-search-add-tag-region'(x = 
`notmuch-search-find-thread-id-region')
  - `notmuch-search-remove-tag-region' (x = 
`notmuch-search-find-thread-id-region')
  - `notmuch-search-remove-tag'(x = 
`notmuch-search-find-thread-id-region')
  - `notmuch-search-operate-all'   (x = `notmuch-search-query-string')


test/emacs, test/emacs-search-operate-all, test/notmuch-test

- Expand the test suite to also cover:
  - Tagging messages with `notmuch-search-operate-all'.
  - Tagging messages to which a reply is sent. For this I also needed to
correct the title of an existing test, and add a test for sending
replies from within Emacs.


Side note:
  After playing around with Austin's new patch for a bit, I've come to the
  conclusion that making a clear distinction between matched and unmatched
  messages in the binary's output *is* the way to go, but in the case of
  `notmuch-search-operate-all', this capability shouldn't be leveraged.

  The way `notmuch-search-operate-all' currently works, i.e. operate on
  matched *messages* instead of matched *threads*, is not only counter-
  intuitive (same as it would be for `notmuch-search-add-tag' and
  `notmuch-search-remove-tag' [2]), but semantically incorrect as well:
  Its name implies operating on *all* that is visible in the current
  buffer, instead of only a subset.


Peace

[1] id:"1310307099-25197-1-git-send-email-pieter at praet.org"
[2] id:"e8c5fbf4-4dfa-461a-8f5c-6c696291a270 at email.android.com"


Signed-off-by: Pieter Praet 
---
 emacs/notmuch.el  |   93 -
 notmuch-search.c  |6 ++-
 test/emacs|   49 +-
 test/emacs-search-operate-all |   29 +
 test/notmuch-test |1 +
 5 files changed, 147 insertions(+), 31 deletions(-)
 create mode 100755 test/emacs-search-operate-all

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index f11ec24..400adcc 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -226,6 +226,7 @@ For a mouse binding, return nil."
 (defvar notmuch-sear

[PATCH v2] emacs: bad regexp @ `notmuch-search-process-filter'

[Austin Clements]

Quoth Pieter Praet on Jul 11 at 10:43 pm:
> TL;DR: I can haz regex pl0x?

Oof, what a pain.  I'm happy to change the output format of search; I
hadn't realized how difficult it would be to parse.  In fact, I'm not
sure it's even parsable by regexp, because the message ID's themselves
could contain parens.

So what would be a good format?  One possibility would be to
NULL-delimit the query part; as distasteful as I find that, this part
of the search output isn't meant for user consumption.  Though I fear
this is endemic to the dual role the search output currently plays as
both user and computer readable.

I've also got the code to do everything using document ID's instead of
message ID's.  As a side-effect, it makes the search output clean and
readily parsable since document ID's are just numbers.  Hence, there
are no quoting or escaping issues (plus the output is much more
compact).  I haven't sent this to the list yet because I haven't had a
chance to benchmark it and determine if the performance benefits make
exposing document ID's worthwhile.

Slowness (search opens every email file?)

[Patrick Totzke]

Hi Jason,
On Mon, Jul 11, 2011 at 03:07:21PM -0400, Jason Woofenden wrote:
> notmuch search tag:foo is slow!
> 
yes, i've just used the vim ui for the first time and i agreee, its sluggish,
searching for * takes a while.

> (when my e-mail files are not already in the disk cache)
> 
> I saw on my activity monitor applet that it was using mostly i/o,
> and started to wonder if it was opening every e-mail. I little work
> with strace and searching revealed that this command was opening
> many many e-mail files from my maildir(s). I spent a little while
> digging around in the notmuch source, and didn't see where it was
> opening the email files.

I cannot reproduce this. I'm no expert, but at least the output of 
 strace vim -c ":NotMuch" 2>log
does not contain any path that matches that of my maildir.
Also, I wout be surprised if all individual mails would be read,
because for this, a search for all messages feels too fast.

> 2) Do you agree that it should instead get this information from
> the database?
agreed. And If the mail files get read on every search for you,
something is definately going wrong there.

A quick browse through notmuch.vim tells me that 
1) it doesn't use notmuchs json output, i think it should, as iirc
this api is considered 'more stable' and is easier to parse than the 
default output. More importantly,
2) the output of notmuch is copied into a list. This will of course
be slow if your query matches a lot of messages. Could this be done
by asyncronously writing to the buffer somehow?

best,
/p
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110711/4158f4c2/attachment.pgp>

Slowness (search opens every email file?)

[Austin Clements]

On Mon, Jul 11, 2011 at 3:07 PM, Jason Woofenden  wrote:
> notmuch search tag:foo is slow!
>
> (when my e-mail files are not already in the disk cache)
>
> I saw on my activity monitor applet that it was using mostly i/o,
> and started to wonder if it was opening every e-mail. I little work
> with strace and searching revealed that this command was opening
> many many e-mail files from my maildir(s). I spent a little while
> digging around in the notmuch source, and didn't see where it was
> opening the email files.

It is opening every file to get a few headers to display in the search
output.  Istvan Marko sent an experimental patch to store these
headers in the database a while ago, though as far as I know there
hasn't been any progress cleaning it up for inclusion:
id:"m3sjsv2kw2.fsf at zsu.kismala.com" .

[PATCH 2/2] tags_to_maildir_flags: Don't rename if no flags change

[Austin Clements]

Quoth Louis Rilling on Jul 12 at 12:38 am:
> On 11/07/11 16:07 -0400, Austin Clements wrote:
> > I worry that this may compound the confusion caused by mutt's handling
> > of the new flag, but I suppose people aren't likely to manipulate any
> > of the other maildir-synchronized flags without also marking the
> > message as seen.
> 
> Even if they don't mark the message as seen, any flag changed would
> move the message to cur/. The only buggy behavior would be from
> mutt, with the bug you mentioned about mutt putting messages with
> flags back to new/.

Yes.  I was thinking of someone tagging a message as, say, flagged,
while it's still tagged unread.  Then it would change from new to old
in mutt.  OTOH, adding some other non-synchronized tag wouldn't change
it from new to old.  I don't think there is a "correct" solution; your
approach is probably the best compromise.

> > The convention in notmuch is to use notmuch_bool_t, TRUE, and FALSE
> > (though, admittedly, I don't know why; avoiding C99-isms?)
> 
> And bool is already used at another place in message.cc:
> 
>   struct maildir_flag_tag {
>   char flag;
>   const char *tag;
>   bool inverse;
>   };
> 
> IIUC it should be changed to notmuch_bool_t too.

Yes, I suppose it should (something slipped by cworth's eagle-eyed
reviews!).  Though that appears to be the sole use of bool in all of
libnotmuch.

[PATCH v2] tags_to_maildir_flags: Don't rename if no flags change

[Austin Clements]

LGTM.

Quoth Louis Rilling on Jul 12 at 12:41 am:
> notmuch_message_tags_to_maildir_flags() unconditionally moves messages from
> maildir directory "new/" to maildir directory "cur/", which makes messages 
> lose
> their "new" status in the MUA. However some users want to keep this "new"
> status after, for instance, an auto-tagging of new messages.
> 
> However, as Austin mentioned and according to the maildir specification,
> messages living in "new/" are not allowed to have flags, even if mutt allows 
> it
> to happen. For this reason, this patch prevents moving messages from "new/" to
> "cur/", only if no flags have to be changed. It's hopefully enough to satisfy
> mutt (and maybe other MUAs showing the "new" status) users checking the "new"
> status.
> 
> Changelog:
> * v2: Fix bool type as well as NULL returned despite having no errors (Austin
>   Clements)
> 
> Signed-off-by: Louis Rilling 
> ---
>  lib/message.cc |   12 +++-
>  1 files changed, 11 insertions(+), 1 deletions(-)
> 
> diff --git a/lib/message.cc b/lib/message.cc
> index 64b6cf8..3f8c4ba 100644
> --- a/lib/message.cc
> +++ b/lib/message.cc
> @@ -1139,7 +1139,7 @@ _get_maildir_flag_actions (notmuch_message_t *message,
>   * compute the new maildir filename.
>   *
>   * If the existing filename is in the directory "new", the new
> - * filename will be in the directory "cur".
> + * filename will be in the directory "cur", unless no flags are changed.
>   *
>   * After a sequence of ":2," in the filename, any subsequent
>   * single-character flags will be added or removed according to the
> @@ -1162,6 +1162,7 @@ _new_maildir_filename (void *ctx,
>  char *filename_new, *dir;
>  char flag_map[128];
>  int flags_in_map = 0;
> +notmuch_bool_t flags_changed = FALSE;
>  unsigned int i;
>  char *s;
>  
> @@ -1202,6 +1203,7 @@ _new_maildir_filename (void *ctx,
>   if (flag_map[flag] == 0) {
>   flag_map[flag] = 1;
>   flags_in_map++;
> + flags_changed = TRUE;
>   }
>  }
>  
> @@ -1210,9 +1212,17 @@ _new_maildir_filename (void *ctx,
>   if (flag_map[flag]) {
>   flag_map[flag] = 0;
>   flags_in_map--;
> + flags_changed = TRUE;
>   }
>  }
>  
> +/* No need to rename. Messages in new/ can be kept in new/.
> + * Note: We don't even try to fix buggy messages having flags and living 
> in
> + * new/. It's not our business.
> + */
> +if (!flags_changed)
> + return talloc_strdup (ctx, filename);
> +
>  filename_new = (char *) talloc_size (ctx,
>info - filename +
>strlen (":2,") + flags_in_map + 1);