[PATCH] Emacs: Add variable to toggle message indentation in a thread
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
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
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
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?
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
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
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
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
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
--- 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
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
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
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/
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
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
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
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
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
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
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?)
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
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
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'
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'
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?)
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?)
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
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
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
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
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
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
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)
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/*
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
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
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
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
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
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
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?
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
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
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
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
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
--- 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
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
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
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/
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
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
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
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
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
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
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?)
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
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
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'
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'
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?)
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?)
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
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
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);