[PATCH v2 1/9] emacs: Consistently use configured sort order

Previously, if `notmuch-search' was called interactively (bound to "s" in search and show, but not hello), it would always use newest-first. However, `notmuch-hello-search' (bound to "s" in hello) and `notmuch-hello-widget-search` would call it with the user-configured sort order. This

[PATCH v2 0/9] emacs: Unify common key bindings and lots more

This is v2 of id:1377793557-28878-1-git-send-email-amdragon at mit.edu. This fixes a problem found by Jani where notmuch-hello would reset point placement when refreshing in Emacs 24. It also inverts the sense of notmuch-hello-auto-refresh and makes it a defcustom (originally I'd intended

[PATCH v2 4/9] emacs: Remove notmuch-search quit continuation

Since notmuch-hello doesn't need this any more, we can remove this hack. This also eliminates `notmuch-search-quit', so now all modes bind q to `notmuch-kill-this-buffer'. --- emacs/notmuch.el | 22 +- 1 file changed, 5 insertions(+), 17 deletions(-) diff --git

[PATCH v2 2/9] emacs: Refresh hello whenever the user switches to the buffer

Previously, we refreshed hello when the user quit a search that was started from hello. This is fine assuming purely stack-oriented buffer use, but is quite fragile and requires hacks to search. This replaces that logic with a new approach that refreshes hello whenever the user switches to the

[PATCH v2 3/9] emacs: Bind s to notmuch-search in hello-mode

Since there is now no difference between notmuch-hello-search and notmuch-search when called interactively, bind s to notmuch-search in notmuch-hello-mode-map. Now all modes bind s this way. --- emacs/notmuch-hello.el |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

[PATCH v2 6/9] emacs: Add unified refresh-this-buffer function

This unifies the various refresh and poll-and-refresh functions we have for different modes. Now all modes bind = and G (except show, which doesn't bind G for some reason) to `notmuch-refresh-this-buffer' and `notmuch-poll-and-refresh-this-buffer', respectively. --- emacs/notmuch-hello.el | 12

[PATCH v2 5/9] emacs: Move `notmuch-poll' to notmuch-lib

--- emacs/notmuch-lib.el | 38 ++ emacs/notmuch.el | 38 -- 2 files changed, 38 insertions(+), 38 deletions(-) diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el index 4796f17..9754e16 100644 ---

[PATCH v2 8/9] emacs: Define a common shared keymap for all of notmuch

This defines a single, currently empty keymap that all other notmuch mode maps inherit from. --- emacs/notmuch-hello.el | 10 -- emacs/notmuch-lib.el |5 + emacs/notmuch-show.el |1 + emacs/notmuch.el |1 + 4 files changed, 15 insertions(+), 2 deletions(-) diff

[PATCH v2 7/9] emacs: Make notmuch-help work with arbitrary keymaps

This converts notmuch-help to use map-keymap for all keymap traversal. This generally cleans up and simplifies construction of keymap documentation, and also makes notmuch-help support anything that can be in a keymap, including more esoteric stuff like multiple inheritance. --- emacs/notmuch.el

[PATCH v2 0/9] emacs: Unify common key bindings and lots more

This is v2 of id:1377793557-28878-1-git-send-email-amdra...@mit.edu. This fixes a problem found by Jani where notmuch-hello would reset point placement when refreshing in Emacs 24. It also inverts the sense of notmuch-hello-auto-refresh and makes it a defcustom (originally I'd intended

[PATCH v2 9/9] emacs: Move ?, q, s, m, =, and G to the common keymap

The only user-visible effect of this should be that G now works in show mode (previously it was unbound for no apparent reason). This shared keymap gives us one place to put global commands, which both forces us to think about what commands should be global, and ensures their bindings can't

[PATCH v2 1/9] emacs: Consistently use configured sort order

Previously, if `notmuch-search' was called interactively (bound to s in search and show, but not hello), it would always use newest-first. However, `notmuch-hello-search' (bound to s in hello) and `notmuch-hello-widget-search` would call it with the user-configured sort order. This inconsistency

[PATCH] emacs: insert quotable parts in reply as they are displayed in show view

ted parts as they are rendered in show view. > >We use a temp buffer to not leak text properties from the show >renderer into the reply. This way we also don't need to worry about >narrowing or point placement. Credits to Mark Walters > and Austin Clements for >getting this part stra

Re: [PATCH v2] emacs: insert quotable parts in reply as they are displayed in show view

Quoth Mark Walters on Aug 30 at 5:49 pm: In reply, insert quotable parts using notmuch-show-insert-bodypart instead of calling notmuch-mm-display-part-inline directly to render the quoted parts as they are rendered in show view. The notable change is that replies to text/calendar

Re: [PATCH] emacs: insert quotable parts in reply as they are displayed in show view

as they are rendered in show view. We use a temp buffer to not leak text properties from the show renderer into the reply. This way we also don't need to worry about narrowing or point placement. Credits to Mark Walters markwalters1...@gmail.com and Austin Clements amdra...@mit.edu for getting

[PATCH v2] emacs: insert quotable parts in reply as they are displayed in show view

Quoth Mark Walters on Aug 30 at 5:49 pm: > > > In reply, insert quotable parts using notmuch-show-insert-bodypart > > instead of calling notmuch-mm-display-part-inline directly to render > > the quoted parts as they are rendered in show view. > > > > The notable change is that replies to

[PATCH 9/9] emacs: Move ?, q, s, m, =, and G to the common keymap

The only user-visible effect of this should be that "G" now works in show mode (previously it was unbound for no apparent reason). --- emacs/notmuch-hello.el |6 -- emacs/notmuch-lib.el |6 ++ emacs/notmuch-show.el |5 - emacs/notmuch.el |6 -- 4 files

[PATCH 8/9] emacs: Define a common shared keymap for all of notmuch

This defines a single, currently empty keymap that all other notmuch mode maps inherit from. --- emacs/notmuch-hello.el | 10 -- emacs/notmuch-lib.el |5 + emacs/notmuch-show.el |1 + emacs/notmuch.el |1 + 4 files changed, 15 insertions(+), 2 deletions(-) diff

[PATCH 7/9] emacs: Make notmuch-help work with arbitrary keymaps

This converts notmuch-help to use map-keymap for all keymap traversal. This generally cleans up and simplifies construction of keymap documentation, and also makes notmuch-help support anything that can be in a keymap, including more esoteric stuff like multiple inheritance. --- emacs/notmuch.el

[PATCH 6/9] emacs: Add unified refresh-this-buffer function

This unifies the various refresh and poll-and-refresh functions we have for different modes. Now all modes bind "=" and "G" (except show, which doesn't bind "G" for some reason) to `notmuch-refresh-this-buffer' and `notmuch-poll-and-refresh-this-buffer', respectively. --- emacs/notmuch-hello.el

[PATCH 5/9] emacs: Move `notmuch-poll' to notmuch-lib

--- emacs/notmuch-lib.el | 38 ++ emacs/notmuch.el | 38 -- 2 files changed, 38 insertions(+), 38 deletions(-) diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el index 4796f17..9754e16 100644 ---

[PATCH 4/9] emacs: Remove notmuch-search quit continuation

Since notmuch-hello doesn't need this any more, we can remove this hack. This also eliminates `notmuch-search-quit', so now all modes bind "q" to `notmuch-kill-this-buffer'. --- emacs/notmuch.el | 22 +- 1 file changed, 5 insertions(+), 17 deletions(-) diff --git

[PATCH 3/9] emacs: Bind "s" to notmuch-search in hello-mode

Since there is now no difference between notmuch-hello-search and notmuch-search when called interactively, bind "s" to notmuch-search in notmuch-hello-mode-map. Now all modes bind "s" this way. --- emacs/notmuch-hello.el |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

[PATCH 2/9] emacs: Refresh hello whenever the user switches to the buffer

Previously, we refreshed hello when the user quit a search that was started from hello. This is fine assuming purely stack-oriented buffer use, but is quite fragile and requires hacks to search. This replaces that logic with a new approach that refreshes hello whenever the user switches to the

[PATCH 1/9] emacs: Consistently use configured sort order

Previously, if `notmuch-search' was called interactively (bound to "s" in search and show, but not hello), it would always use newest-first. However, `notmuch-hello-search' (bound to "s" in hello) and `notmuch-hello-widget-search` would call it with the user-configured sort order. This

[PATCH 0/9] emacs: Unify common key bindings and lots more

This series moves several common key bindings into a shared notmuch-wide keymap. To get there, it first cleans up several things so that all notmuch modes have common commands to put into a common keymap. In the process, this fixes inconsistent sort ordering reported in id:m2bo5c5h8l.fsf at

[PATCH 3/9] emacs: Bind s to notmuch-search in hello-mode

Since there is now no difference between notmuch-hello-search and notmuch-search when called interactively, bind s to notmuch-search in notmuch-hello-mode-map. Now all modes bind s this way. --- emacs/notmuch-hello.el |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

[PATCH 7/9] emacs: Make notmuch-help work with arbitrary keymaps

This converts notmuch-help to use map-keymap for all keymap traversal. This generally cleans up and simplifies construction of keymap documentation, and also makes notmuch-help support anything that can be in a keymap, including more esoteric stuff like multiple inheritance. --- emacs/notmuch.el

[PATCH 2/9] emacs: Refresh hello whenever the user switches to the buffer

Previously, we refreshed hello when the user quit a search that was started from hello. This is fine assuming purely stack-oriented buffer use, but is quite fragile and requires hacks to search. This replaces that logic with a new approach that refreshes hello whenever the user switches to the

[PATCH 9/9] emacs: Move ?, q, s, m, =, and G to the common keymap

The only user-visible effect of this should be that G now works in show mode (previously it was unbound for no apparent reason). --- emacs/notmuch-hello.el |6 -- emacs/notmuch-lib.el |6 ++ emacs/notmuch-show.el |5 - emacs/notmuch.el |6 -- 4 files

[PATCH 8/9] emacs: Define a common shared keymap for all of notmuch

This defines a single, currently empty keymap that all other notmuch mode maps inherit from. --- emacs/notmuch-hello.el | 10 -- emacs/notmuch-lib.el |5 + emacs/notmuch-show.el |1 + emacs/notmuch.el |1 + 4 files changed, 15 insertions(+), 2 deletions(-) diff

[PATCH 1/9] emacs: Consistently use configured sort order

Previously, if `notmuch-search' was called interactively (bound to s in search and show, but not hello), it would always use newest-first. However, `notmuch-hello-search' (bound to s in hello) and `notmuch-hello-widget-search` would call it with the user-configured sort order. This inconsistency

[PATCH 6/9] emacs: Add unified refresh-this-buffer function

This unifies the various refresh and poll-and-refresh functions we have for different modes. Now all modes bind = and G (except show, which doesn't bind G for some reason) to `notmuch-refresh-this-buffer' and `notmuch-poll-and-refresh-this-buffer', respectively. --- emacs/notmuch-hello.el | 12

[PATCH 4/9] emacs: Remove notmuch-search quit continuation

Since notmuch-hello doesn't need this any more, we can remove this hack. This also eliminates `notmuch-search-quit', so now all modes bind q to `notmuch-kill-this-buffer'. --- emacs/notmuch.el | 22 +- 1 file changed, 5 insertions(+), 17 deletions(-) diff --git

[PATCH 5/9] emacs: Move `notmuch-poll' to notmuch-lib

--- emacs/notmuch-lib.el | 38 ++ emacs/notmuch.el | 38 -- 2 files changed, 38 insertions(+), 38 deletions(-) diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el index 4796f17..9754e16 100644 ---

Feature proposal: OUTPUT_AUTHOR format

Quoth Johannes Kulick on Aug 27 at 1:50 pm: > Hi David, > > Quoting David Bremner (2013-08-27 02:27:00) > > I'm not sure I understand your goal completely here, but the obvious > > thing UI wise would be > > > > notmuch search --output=authors --format=(json|text|sexp) $search_terms > >

Re: Feature proposal: OUTPUT_AUTHOR format

Quoth Johannes Kulick on Aug 27 at 1:50 pm: Hi David, Quoting David Bremner (2013-08-27 02:27:00) I'm not sure I understand your goal completely here, but the obvious thing UI wise would be notmuch search --output=authors --format=(json|text|sexp) $search_terms Perhaps

[PATCH v2] test: Canonicalize RFC 2047 encoding and charset

RFC 2047 states that the encoding and charset in an encoded word are case-insensitive, so force them to lower case in the reply test. This fixes an issue caused by GMime versions (somewhere between 2.6.10 and 2.6.16), which changed the capitalization of the encoding. --- test/reply |8

[PATCH] test: Canonicalize RFC 2047 encoding and charset

RFC 2047 states that the encoding and charset in an encoded word are case-insensitive, so force them to lower case in the reply test. This fixes an issue caused by GMime versions (somewhere between 2.6.10 and 2.6.16), which changed the capitalization of the encoding. --- test/reply |8

[PATCH v3 3/3] reply: Use RFC 2822/MIME wholly for text format template

Previously, reply's default text format used an odd mix of RFC 2045 MIME encoding for the reply template's body and some made-up RFC 2822-like UTF-8 format for the headers. The intent was to present the headers to the user in a nice, un-encoded format, but this assumed that whatever ultimately

[PATCH v3 2/3] reply: Remove extraneous space from generated References

Previously, the References header code seemed to assume notmuch_message_get_header would return NULL if the header was not present, but it actually returns "". As a result of this, it was inserting an unnecessary space when concatenating an empty or missing original references header with the new

[PATCH v3 1/3] reply: Test replying to messages with RFC 2047-encoded headers

--- test/reply | 56 1 file changed, 56 insertions(+) diff --git a/test/reply b/test/reply index ee5d361..c877ffe 100755 --- a/test/reply +++ b/test/reply @@ -193,4 +193,60 @@ References: <${gen_msg_id}> On Tue, 05 Jan 2010 15:43:56

[PATCH v3 0/3] Clean up reply's encoding story

This is v3 of id:1376587658-19202-1-git-send-email-amdragon at mit.edu. This addresses Jani's comment in id:87k3jl3ehe.fsf at nikula.org by treating errors while retrieving the original message's References header as if the original message didn't have a References header. It also adds a comment

[PATCH v2 2/3] reply: Remove extraneous space from generated References

Quoth Jani Nikula on Aug 16 at 5:19 pm: > On Thu, 15 Aug 2013, Austin Clements wrote: > > Previously, the References header code seemed to assume > > notmuch_message_get_header would return NULL if the header was not > > present, but it actually ret

[PATCH v2 3/3] reply: Use RFC 2822/MIME wholly for text format template

Previously, reply's default text format used an odd mix of RFC 2045 MIME encoding for the reply template's body and some made-up RFC 2822-like UTF-8 format for the headers. The intent was to present the headers to the user in a nice, un-encoded format, but this assumed that whatever ultimately

[PATCH v2 2/3] reply: Remove extraneous space from generated References

Previously, the References header code seemed to assume notmuch_message_get_header would return NULL if the header was not present, but it actually returns "". As a result of this, it was inserting an unnecessary space when concatenating an empty or missing original references header with the new

[PATCH v2 1/3] reply: Test replying to messages with RFC 2047-encoded headers

--- test/reply | 56 1 file changed, 56 insertions(+) diff --git a/test/reply b/test/reply index ee5d361..c877ffe 100755 --- a/test/reply +++ b/test/reply @@ -193,4 +193,60 @@ References: <${gen_msg_id}> On Tue, 05 Jan 2010 15:43:56

[PATCH v2 0/3] Clean up reply's encoding story

This is v2 of id:1376332839-22825-1-git-send-email-amdragon at mit.edu. This fixes an unintentional temporary test breakage and two typos in the last patch's commit message. There's no version diff from v1 because the final trees are the same.

[PATCH 0/6] Clean up reply's encoding story

Quoth Tomi Ollila on Aug 14 at 8:04 pm: > On Mon, Aug 12 2013, Austin Clements wrote: > > > Jeff Stedfast's email about gmime-filter-headers.c possibly being > > unnecessary with GMime 2.6 (quoted in id:87bo56viyo.fsf at nikula.org) > > sent me on a wild goose chas

[PATCH] test: Make symbol-test depend on libnotmuch.so

Without this $ make -j test intermittently fails and $ make clean; make test/symbol-test always fails (not that anybody would do the latter). --- test/Makefile.local |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/test/Makefile.local b/test/Makefile.local index

[PATCH 4/6] reply: Test replying to messages with RFC 2047-encoded headers

On Mon, 12 Aug 2013, Austin Clements wrote: > --- > test/reply | 56 > 1 file changed, 56 insertions(+) > > diff --git a/test/reply b/test/reply > index ee5d361..a85ebe5 100755 > --- a/test/reply > +++ b/test/r

[PATCH 6/6] reply: Use RFC 2822/MIME wholly for text format template

t; length there is not much of note here. Note that the length of 200 bytes > includes the Subject: and Re: prefixes with two spaces > +Subject: Re: This subject is exactly 200 bytes in length. Other than its > + length there is not much of note here. Note that the length of 200 bytes > + includes the Subject: and Re: prefixes with two spaces > In-Reply-To: <${gen_msg_id}> > References: <${gen_msg_id}> > > @@ -200,10 +202,11 @@ add_message '[subject]="=?iso-8859-1?q?=e0=df=e7?="' \ > '[body]="Encoding"' > > output=$(notmuch reply id:${gen_msg_id}) > +# Note that GMime changes from Q- to B-encoding > test_expect_equal "$output" "\ > From: Notmuch Test Suite > -Subject: Re: ??? > -To: ? > +Subject: Re: =?iso-8859-1?b?4N/n?= > +To: =?UTF-8?b?4piD?= > In-Reply-To: <${gen_msg_id}> > References: <${gen_msg_id}> > > diff --git a/test/reply-to-sender b/test/reply-to-sender > index c7d15bb..30e5e38 100755 > --- a/test/reply-to-sender > +++ b/test/reply-to-sender > @@ -200,7 +200,9 @@ add_message '[subject]="This subject is exactly 200 bytes > in length. Other than > '[body]="200-byte header"' > output=$(notmuch reply --reply-to=sender id:${gen_msg_id}) > test_expect_equal "$output" "From: Notmuch Test Suite notmuchmail.org> > -Subject: Re: This subject is exactly 200 bytes in length. Other than its > length there is not much of note here. Note that the length of 200 bytes > includes the Subject: and Re: prefixes with two spaces > +Subject: Re: This subject is exactly 200 bytes in length. Other than its > + length there is not much of note here. Note that the length of 200 bytes > + includes the Subject: and Re: prefixes with two spaces > In-Reply-To: <${gen_msg_id}> > References: <${gen_msg_id}> > -- Austin Clements MIT/'06/PhD/CSAIL amdragon at mit.edu http://web.mit.edu/amdragon Somewhere in the dream we call reality you will find me, searching for the reality we call dreams.

[PATCH 6/6] reply: Use RFC 2822/MIME wholly for text format template

Previously, reply's default text format used an odd mix of RFC 2045 MIME encoding for the reply template's body and some made-up RFC 2822-like UTF-8 format for the headers. The intent was to present the headers to the user in a nice, un-encoded format, but this assumed that whatever ultimately

[PATCH 5/6] reply: Remove extraneous space from generated References

Previously, the References header code seemed to assume notmuch_message_get_header would return NULL if the header was not present, but it actually returns "". As a result of this, it was inserting an unnecessary space when concatenating an empty or missing original references header with the new

[PATCH 4/6] reply: Test replying to messages with RFC 2047-encoded headers

--- test/reply | 56 1 file changed, 56 insertions(+) diff --git a/test/reply b/test/reply index ee5d361..a85ebe5 100755 --- a/test/reply +++ b/test/reply @@ -193,4 +193,60 @@ References: <${gen_msg_id}> On Tue, 05 Jan 2010 15:43:56

[PATCH 3/6] reply: Document the reason for g_mime_filter_headers

Given how long it took me to figure out why we pass the reply headers through g_mime_filter_headers, it's worth a comment. --- notmuch-reply.c |4 1 file changed, 4 insertions(+) diff --git a/notmuch-reply.c b/notmuch-reply.c index e151f78..3b2b58d 100644 --- a/notmuch-reply.c +++

[PATCH 2/6] lib: Document which strings are returned in UTF-8

Any string that ultimately comes from notmuch_message_file_get_header is in UTF-8. --- lib/notmuch-private.h |2 +- lib/notmuch.h |6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/lib/notmuch-private.h b/lib/notmuch-private.h index cc55bb9..eced03e 100644

[PATCH 1/6] lib: Correct out-of-date doc comment

notmuch_message_get_header started returning some headers straight from the database in 567bcbc, but this comment explicitly claimed all headers were read from the message file. --- lib/notmuch.h |7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/lib/notmuch.h

[PATCH 0/6] Clean up reply's encoding story

Jeff Stedfast's email about gmime-filter-headers.c possibly being unnecessary with GMime 2.6 (quoted in id:87bo56viyo.fsf at nikula.org) sent me on a wild goose chase that led to this patch series. It turned out that we *did* need gmime-filter-headers for what we were doing in the reply text

Possible addtions to notmuch new ?

Quoth Vladimir Marek on Aug 12 at 11:34 am: > Hi, > > My mail setup is a directory containing several subdirectories each > subdirectory corresponds to one real mail account I am using. Each mail > account is synchronized differently - I am using offlineimap, fetchmeail > or even synthetically

unread message appear `folded'

Quoth Ramakrishnan Muthukrishnan on Aug 05 at 11:35 pm: > Ramakrishnan Muthukrishnan writes: > > > Hi, > > > > Pardon me for using non-standard terms here because of lack of knowledge > > of the language used in the email world. > > > > I have this thread in which some messages are tagged

problems viewing attachments in emacs ui

Quoth myself on Jul 30 at 10:53 pm: > Quoth Jameson Graef Rollins on Jul 28 at 10:06 am: > > On Sun, Jul 28 2013, Jameson Graef Rollins > > wrote: > > > For instance, if I launch notmuch-show-view-part on an html part, my > > > browser opens pointed at e.g. the following file: > > > > > >

problems viewing attachments in emacs ui

Quoth myself on Jul 30 at 10:53 pm: > Quoth Jameson Graef Rollins on Jul 28 at 10:06 am: > > On Sun, Jul 28 2013, Jameson Graef Rollins > > wrote: > > > For instance, if I launch notmuch-show-view-part on an html part, my > > > browser opens pointed at e.g. the following file: > > > > > >

problems viewing attachments in emacs ui

Quoth Jameson Graef Rollins on Jul 28 at 10:06 am: > On Sun, Jul 28 2013, Jameson Graef Rollins > wrote: > > For instance, if I launch notmuch-show-view-part on an html part, my > > browser opens pointed at e.g. the following file: > > > > file:///home/jrollins/tmp/emm.610040w/mm.6100F_2.htm >

[PATCH] emacs: bugfix attachment content-type as mime-type handling

Quoth Mark Walters on Jul 30 at 5:15 pm: > Notmuch puts attachments in as declared content-type except when the > content-type is application/octet-stream it tries to guess the type > from the filename/extension. This means that viewing a pdf (for > example) which is sent as

[PATCH] Put 0.16 NEWS in a reasonable order

The 0.16 NEWS grew chronologically during development, and as a result wound up in a particularly odd order. This rearranges it to put the most user-visible news first. Roughly: new features, modified behavior, bug fixes, then deprecation, with related items grouped. This does not modify the

[PATCH] emacs: News for S-expressions everywhere

Update the news about search using S-expression support to also say that show is also now faster. --- NEWS |7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/NEWS b/NEWS index 0537fb4..b88575e 100644 --- a/NEWS +++ b/NEWS @@ -85,11 +85,12 @@ Better handling of errors in

How to find mails which are sent to 'undisclosed-recipients' ?

Quoth Vladimir Marek on Jul 11 at 8:03 pm: > > > Since my mail works in a way that it hides everything but what I > > > selected to be shown to me, I was overlooking all mails which where sent > > > to undisclosed-recipients. I tried to match such mails by > > > to:undisclosed-recipients but that

[PATCH 2/2] notmuch.el:notmuch-search-process-filter: Rewritten. Cope with incomplete lines.

On Tue, 15 Nov 2011, Thomas Schwinge wrote: > Hi! > > On Thu, 10 Mar 2011 18:02:09 -0800, Carl Worth wrote: >> On Thu, 3 Feb 2011 00:56:39 +0100, Thomas Schwinge > schwinge.name> wrote: >> > This issue has been lying in ambush as of 2009-11-24's commit >> >

[PATCH] emacs: Echo the output of notmuch new as it runs

Previously, when the user pressed "G" to invoke notmuch new, Emacs would go out to lunch until it finished, giving the user no sense that the (potentially long-running) notmuch new process was making progress. This patch fixes this by continuously updating the echo area to display the last output

[PATCH 1/3] emacs: Introduce `notmuch-call-notmuch-sexp'

son (3 files with (require 'json) and the > async json parser) too? > > Best wishes > > Mark > > On Mon, 24 Jun 2013, Austin Clements wrote: > > This is just like `notmuch-call-notmuch-json', but parses S-expression > > output. Note that, also like `notmuch-call-notmuch-j

[PATCH 3/3] emacs: Remove `notmuch-call-notmuch-json'

This function is no longer used. --- emacs/notmuch-lib.el | 22 -- 1 file changed, 22 deletions(-) diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el index 36eacc1..da814d5 100644 --- a/emacs/notmuch-lib.el +++ b/emacs/notmuch-lib.el @@ -462,28 +462,6 @@ You may need

[PATCH 2/3] emacs: Use S-exp format everywhere

This switches `notmuch-mua-reply' and `notmuch-query-get-threads' to the S-exp format. These were the last two uses of the JSON format in the Emacs frontend. --- emacs/notmuch-mua.el |4 ++-- emacs/notmuch-query.el |4 ++-- test/emacs-show|2 +- 3 files changed, 5

[PATCH 1/3] emacs: Introduce `notmuch-call-notmuch-sexp'

This is just like `notmuch-call-notmuch-json', but parses S-expression output. Note that, also like `notmuch-call-notmuch-json', this doesn't consider trailing data to be an error, which may or may not be what we want in the long run. --- emacs/notmuch-lib.el | 17 + 1 file

header continuation issue in notmuch frontend/alot/pythons email module

On Sun, 23 Jun 2013, Austin Clements wrote: > There also appears to be a bug in the notmuch CLI's reply command > where it omits addresses that were folded in the original message. I > don't know if alot uses the CLI's reply command, so this may or may > not be related to your specif

header continuation issue in notmuch frontend/alot/pythons email module

Quoth Justus Winter on Jun 23 at 3:11 pm: > Hi, > > I recently had a problem replying to a mail written by Thomas Schwinge > using an oldish notmuch. Not sure if it has been fixed in more recent > versions, but I think notmuch could improve uppon its header > generation (see below). Problematic

[PATCH 1/1] test/basic: replaced find -perm +111 with portable alternative

Quoth Tomi Ollila on Jun 13 at 10:47 pm: > On Mon, Jun 10 2013, Austin Clements wrote: > > > LGTM. Though, I wonder, why not *just* -perm -100? That isn't quite > > a correct test of whether the user can execute it: e.g., if the file > > is owned by some other user and

[RFC PATCH] revert: Removed top level --stderr= option

LGTM. While I thought --stderr was a fine solution originally, now that we've stumbled across problems that make it difficult to use correctly and robustly, I think Tomi's right that we should probably revert it. On Fri, 31 May 2013, Tomi Ollila wrote: > While looked good on paper, its

[PATCH 1/1] test/basic: replaced find -perm +111 with portable alternative

LGTM. Though, I wonder, why not *just* -perm -100? That isn't quite a correct test of whether the user can execute it: e.g., if the file is owned by some other user and a group the current user isn't in, then -perm -1 is the correct test, though unless the file has some unusual permissions,

[PATCH v5 0/6] emacs: show: lazy handling of hidden parts

LGTM. Quoth Mark Walters on Jun 10 at 5:57 am: > This is version 5 of this patch set. Version 4 is at > id:1370074547-24677-1-git-send-email-markwalters1009 at gmail.com. > > This version fixes the two bugs pointed out in Austin's review > id:20130610023952.GC22196 at mit.edu. > > I decided to

[PATCH v4 0/5] emacs: show: lazy handling of hidden parts

Quoth Mark Walters on Jun 01 at 9:15 am: > This is version 4 of this series. Version 3 is at > id:1370024806-6616-1-git-send-email-markwalters1009 at gmail.com > > Changes from version 3 are: fix the whitespace changes in patch 3/5, > store both the start of the part and the start of the content

[PATCH 2/2] emacs: Fix "no such file or directory" error

Quoth Mark Walters on Jun 09 at 10:16 am: > > Both of these patches look good to me +1. I was able to reproduce both > bugs pretty reliably (the first one always unless masked by the second > one which occurred about half the time). With these patches I cannot > trigger either. Also all tests

[PATCH 2/2] emacs: Fix "no such file or directory" error

Occasionally, when the user killed the search buffer when the CLI process was still running, Emacs would run the notmuch-start-notmuch-sentinel sentinel twice. The first call would process and delete the error output file and the second would fail with an "Opening input file: no such file or

[PATCH 1/2] emacs: Don't report CLI signals sent by Emacs as errors

Previously, when the user killed the search buffer before the CLI search process had completed, we would report the signal sent by Emacs to kill the CLI to the user as an error. Fix this by only reporting error exits if the process buffer is still live. We still report stderr output regardless

[PATCH 0/2] Fix errors when killing the search buffer

This series fixes the first two problems described by Jameson in id:87r4gk8qa5.fsf at servo.finestructure.net that caused errors to be reported when the search buffer was killed by the user while the search was still running.

[PATCH] emacs: remove hardcoded defaults values from docstrings

Quoth David Bremner on Jun 04 at 8:37 am: > Tomi Ollila writes: > > > On Tue, Jun 04 2013, Austin Clements wrote: > > > >> I realize this already got pushed, but to me this seems like a > >> reversion for the 95% of users who haven't customized > >&g

[PATCH v3 0/6] Make Emacs search use sexp format

On Sun, 02 Jun 2013, Jameson Graef Rollins wrote: > On Sat, Jun 01 2013, David Bremner wrote: >> Austin Clements writes: >> >>> This is v3 of id:1369934016-22308-1-git-send-email-amdragon at mit.edu. >>> This tweaks the shell invocation as suggested by Tom

Error when viewing mails.

Sorry; this one's my fault. You should apply id:1370272679-20175-1-git-send-email-amdragon at mit.edu, which is currently sitting the ready queue, but hasn't been pushed to master yet. Quoth Aneesh Kumar K.V on Jun 04 at 10:43 am: > > I started seeing this with latest notmuch update. > >

[PATCH] emacs: remove hardcoded defaults values from docstrings

I realize this already got pushed, but to me this seems like a reversion for the 95% of users who haven't customized notmuch-archive-tags and just want to know that archiving means removing the inbox tag. Why is this less confusing? Users who have customized notmuch-archive-tags will probably

Re: [PATCH] emacs: remove hardcoded defaults values from docstrings

Quoth David Bremner on Jun 04 at 8:37 am: Tomi Ollila tomi.oll...@iki.fi writes: On Tue, Jun 04 2013, Austin Clements amdra...@mit.edu wrote: I realize this already got pushed, but to me this seems like a reversion for the 95% of users who haven't customized notmuch-archive-tags

[PATCH v2] news: Be louder about s/v/o/| on part buttons going away

This change is likely to affect most people, so put this information right in the news header and be more explicit about it in the news detail. --- As Mark pointed out, I forgot to mention the | part command. NEWS | 19 ++- 1 file changed, 10 insertions(+), 9 deletions(-)

[RFC PATCH] emacs: Remove v command

This removes the v command, since we now have much nicer part commands, and deprecates the underlying notmuch-show-view-all-mime-parts. This also means that people who try using the old unprefixed 'v' command on a part button will no longer be greeted by ALL of their parts popping up. ---

[RFC PATCH 1/2] news: Be louder about s/v/o on part buttons going away

Please ignore this semi-duplicate message. I screwed up my git send-email invocation. Quoth myself on Jun 03 at 11:52 am: > This change is likely to affect most people, so put this information > right in the news header and be more explicit about it in the news > detail.

[RFC PATCH 1/2] news: Be louder about s/v/o on part buttons going away

This change is likely to affect most people, so put this information right in the news header and be more explicit about it in the news detail. --- NEWS | 19 ++- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/NEWS b/NEWS index 6f09cdb..0c0cf82 100644 --- a/NEWS

[PATCH] news: Be louder about s/v/o on part buttons going away

This change is likely to affect most people, so put this information right in the news header and be more explicit about it in the news detail. --- NEWS | 19 ++- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/NEWS b/NEWS index 6f09cdb..0c0cf82 100644 --- a/NEWS

[PATCH] emacs: Fix applying stickiness to the :notmuch-part property

Previously, we simply called pushnew to add :notmuch-part to the front-sticky and rear-nonsticky text property lists. This works if these are nil or lists, but they can also have the value t, meaning that all properties are front-sticky/rear-nonsticky. In this case, pushnew will signal an error

[PATCH] emacs: Fix applying stickiness to the :notmuch-part property

Previously, we simply called pushnew to add :notmuch-part to the front-sticky and rear-nonsticky text property lists. This works if these are nil or lists, but they can also have the value t, meaning that all properties are front-sticky/rear-nonsticky. In this case, pushnew will signal an error

[PATCH] news: Be louder about s/v/o on part buttons going away

This change is likely to affect most people, so put this information right in the news header and be more explicit about it in the news detail. --- NEWS | 19 ++- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/NEWS b/NEWS index 6f09cdb..0c0cf82 100644 --- a/NEWS

Re: [RFC PATCH 1/2] news: Be louder about s/v/o on part buttons going away

Please ignore this semi-duplicate message. I screwed up my git send-email invocation. Quoth myself on Jun 03 at 11:52 am: This change is likely to affect most people, so put this information right in the news header and be more explicit about it in the news detail.

[PATCH v2] news: Be louder about s/v/o/| on part buttons going away

This change is likely to affect most people, so put this information right in the news header and be more explicit about it in the news detail. --- As Mark pointed out, I forgot to mention the | part command. NEWS | 19 ++- 1 file changed, 10 insertions(+), 9 deletions(-)

<    4   5   6   7   8   9   10   11   12   13   >