Re: [PATCH v4 14/16] test indexing cleartext version of delivered messages.

Daniel Kahn Gillmor writes: > This requires a bit of reorganization: > > * add_gnupg_home gets moved to test-lib.sh, and > > * we allow passing --long-arguments to "notmuch new" via >emacs_fcc_message LGTM d ___ notmuch

Re: [PATCH v4 13/16] add indexopts to notmuch python bindings.

Daniel Kahn Gillmor writes: > > +:param indexopts: a nomtuch.Indexopts object indicating custom > +options desired for indexing. > + typo >be added. > + spurious whitespace change? otherwise the patch looks fine. d

Re: [PATCH v4 12/16] add --try-decrypt to notmuch new

Daniel Kahn Gillmor writes: > Try to decrypt any encrypted parts of newly-discovered messages while > indexing them. The cleartext of any successfully-decrypted messages > will be indexed, with tags applied in the same form as from notmuch > insert --try-decrypt.

Re: [PATCH v4 11/16] add --try-decrypt to notmuch insert

Daniel Kahn Gillmor writes: > +status = notmuch_indexopts_set_try_decrypt (indexopts, try_decrypt); > +if (status != NOTMUCH_STATUS_SUCCESS) { > + fprintf (stderr, "Error: Failed to set try_decrypt to %s. (%s)\n", > + try_decrypt ? "True" :

Re: [PATCH v4 10/16] Add n_d_add_message_with_indexopts (extension of n_d_add_message)

Daniel Kahn Gillmor writes: > diff --git a/lib/notmuch.h b/lib/notmuch.h > index b92d969..66b3503 100644 > --- a/lib/notmuch.h > +++ b/lib/notmuch.h > @@ -605,6 +605,20 @@ notmuch_status_t > notmuch_database_add_message (notmuch_database_t *database, >

Re: [PATCH 9/9] add has: query prefix to search for specific properties

Jameson Graef Rollins writes: > Super minor annoying comment, but I wonder if there's a missing colon in > the above addition: > >> + **tag:**, **id:**, **thread:**, **folder:**, **path:**, **has:** annoying, but correct ;). d

Re: [PATCH 9/9] add has: query prefix to search for specific properties

On Sat, Aug 06 2016, David Bremner wrote: > @@ -217,7 +224,7 @@ exact matches like "tag:inbox" or **probabilistic**, > supporting a more flexible > > > Boolean > - **tag:**, **id:**, **thread:**, **folder:**, **path:** > + **tag:**, **id:**, **thread:**, **folder:**,

Re: [PATCH v4 09/16] index encrypted parts when asked.

Daniel Kahn Gillmor writes: > +if (status) { > + _notmuch_database_log (notmuch, "Warning: setup failed for decrypting " > +"during indexing. (%d)\n", status); > + status = notmuch_message_add_property (message, "index-decryption",

Re: [PATCH 0/4] Allow specifying alternate names for addresses in other_email

On Tue, 09 Aug 2016, Shea Levy wrote: > Currently, while notmuch-reply will recognize email addresses other than > the main address with user.other_email, it always sets the name part of > the address in the envelope-from and From headers to user.name. This > patchset enables

[PATCH v2 14/14] cli/reply: only pass gmime message to add recipients to reply message

The notmuch message is no longer needed. Simplify. --- notmuch-reply.c | 37 ++--- 1 file changed, 14 insertions(+), 23 deletions(-) diff --git a/notmuch-reply.c b/notmuch-reply.c index abf3a6c1824c..8c894974485d 100644 --- a/notmuch-reply.c +++ b/notmuch-reply.c

[PATCH v2 13/14] cli/reply: pass gmime message to munge detection

Improves the accuracy in many ways. --- notmuch-reply.c | 35 +++ 1 file changed, 23 insertions(+), 12 deletions(-) diff --git a/notmuch-reply.c b/notmuch-reply.c index cf4248bd6794..abf3a6c1824c 100644 --- a/notmuch-reply.c +++ b/notmuch-reply.c @@ -230,13

[PATCH v2 11/14] cli/reply: return internet address list from get header funcs

Pass in GMimeMessage to simplify To/Cc/Bcc headers. We'll eventually remove the notmuch message passing altogether, but keep both for now to not make too big changes at once. Getting the headers from GMimeMessage using GMime functions fixes the error on duplicate Cc headers reported by Daniel

[PATCH v2 12/14] cli/reply: pass internet address list to munge detect

--- notmuch-reply.c | 20 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/notmuch-reply.c b/notmuch-reply.c index 98034485c546..cf4248bd6794 100644 --- a/notmuch-reply.c +++ b/notmuch-reply.c @@ -231,19 +231,18 @@ scan_address_list (InternetAddressList *list,

[PATCH v2 10/14] cli/reply: check for NULL list first in scan_address_list()

Support passing NULL list later on. Also use it to simplify the recursion. --- notmuch-reply.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/notmuch-reply.c b/notmuch-reply.c index 9b78ea2c2b20..d90f46f9bed3 100644 --- a/notmuch-reply.c +++ b/notmuch-reply.c @@ -192,6

[PATCH v2 09/14] cli/reply: use dedicated functions for reply to mapping

The main motivation here is to move the special casing around reply-to/from handling into a function of its own, clarifying the main logic. --- notmuch-reply.c | 82 ++--- 1 file changed, 49 insertions(+), 33 deletions(-) diff --git

[PATCH v2 08/14] cli/reply: reduce the reply format abstractions

Now that we've made the various reply formats quite similar to each other, there's no point in keeping the abstractions. They are now close enough to be put in one function. For now, a mime node will be uselessly created for the headers-only case, but this is insignificant, and may change in the

[PATCH v2 06/14] cli/reply: make references header creation easier to follow

Just use strdup when original references is not available, instead of trying to cram everything into a monster asprintf. There should be no functional changes. --- notmuch-reply.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/notmuch-reply.c b/notmuch-reply.c

[PATCH v2 07/14] cli/reply: reuse create_reply_message() also for headers-only format

Add an option for "limited" headers for the (slightly misleadingly named) headers-only format. There should be no functional changes. --- notmuch-reply.c | 46 +++--- 1 file changed, 15 insertions(+), 31 deletions(-) diff --git a/notmuch-reply.c

[PATCH v2 05/14] cli/reply: reorganize create_reply_message()

Again, in preparation for later unification, reorganize create_reply_message() to be more similar to the open coded version in the headers-only format reply code. Due to "pretty" header ordering, there should be no change in output. There should be no functional changes. --- notmuch-reply.c | 45

[PATCH v2 04/14] cli/reply: unify reply format functions

Prepare for further future unification by making the code similar. The only functional change is that errors in mime_node_open() also break execution in default reply format. --- notmuch-reply.c | 18 ++ 1 file changed, 10 insertions(+), 8 deletions(-) diff --git

[PATCH v2 03/14] cli/reply: reuse show_reply_headers() in headers-only format

Align the code with default format reply. There should be no changes in output. --- notmuch-reply.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/notmuch-reply.c b/notmuch-reply.c index 847e306f94d2..5adbab624ad7 100644 --- a/notmuch-reply.c +++ b/notmuch-reply.c @@

[PATCH v2 02/14] cli/reply: push notmuch reply format abstraction lower in the stack

There's quite a bit of duplication, and some consequent deviation, between the various notmuch reply format code paths. Perform the query and message iteration in common code, and make the format specific functions operate on single messages. There should be no functional changes. ---

[PATCH v2 01/14] test: add known broken test for reply to message with multiple Cc headers

As Daniel Kahn Gillmor reports in id:87d1ngv95p@alice.fifthhorseman.net, notmuch show combines multiple Cc: fields into one, while notmuch reply does not. While such messages are in violation of RFC 5322, it would be reasonable to expect notmuch to be consistent. Add a

[PATCH v2 00/14] reply refactor, fixes

Hi all, this lengthy series fixes replies to messages with multiple Cc: headers. Daniel reported the problem in id:87d1ngv95p@alice.fifthhorseman.net. Lots of refactoring is required to switch to using more GMime functions in the reply code. This is v2 of the series in

Re: [PATCH 9/9] add has: query prefix to search for specific properties

Jani Nikula writes: >> I don't really understand the comment on the next line (since it seems >> that no : is added to XPROPERTY by Xapian), but I guess we should >> probably be consistent. Maybe Jani can explain the comment? > > My recollection is vague, but it has to do with

Re: Applying patches directly from emails?

On Sun, 24 Jul 2016, Nicolas Petton wrote: > Daniel Kahn Gillmor writes: >> If you're asking about notmuch-emacs, I just use "|" (or ". |" if a >> MIME subpart is the patch instead of the whole message) to pipe the >> patch into some command i care

Re: Applying patches directly from emails?

On Sat, 23 Jul 2016, Daniel Kahn Gillmor wrote: > Hi Nicolas-- > > On Fri 2016-07-22 17:02:03 -0400, Nicolas Petton wrote: > >> I'd like to be able to apply patches sent from emails, either as >> attachments or inlined. >> >> Notmuch can show inline patches as diffs, which

Re: [WIP PATCH] emacs: query: completion for from: in searches

On Fri, Aug 12 2016, Mark Walters wrote: > This is a first attempt at tab completion for from: searches > --- Nice work! I did not test this, but tried to get a grasp of it by testing tag: completion -- It took me a while to find out where to test -- in interactive

Re: [PATCH 9/9] add has: query prefix to search for specific properties

On Sat, 06 Aug 2016, David Bremner wrote: > David Bremner writes: > >> >> +The **has:** prefix searches for messages with a particular >> += property pair. Properties are used internally by notmuch >> +(and extensions) to add metadata to messages. A given

Re: [PATCH v4 02/16] Move crypto.c into libutil

Tomi Ollila writes: > On Fri, Aug 12 2016, David Bremner wrote: > >> Daniel Kahn Gillmor writes: >>> +++ b/util/crypto.c >>> @@ -0,0 +1,138 @@ >> >>> +#include "notmuch.h" >> >> It feels wrong to me for a file in util/ to include

Re: [PATCH v4 02/16] Move crypto.c into libutil

On Fri, Aug 12 2016, David Bremner wrote: > Daniel Kahn Gillmor writes: >> +++ b/util/crypto.c >> @@ -0,0 +1,138 @@ > >> +#include "notmuch.h" > > It feels wrong to me for a file in util/ to include notmuch.h. It seems > the same situation holds with