revised patch for gmime init, with test.

[David Bremner]

On Thu, 12 Jan 2012 18:25:38 +0100, Pieter Praet  wrote:
> On Sat, 31 Dec 2011 23:22:46 -0400, David Bremner  
> wrote:

> with differing hashes), this has the potential of causing confusion
> and/or quite some extra work when debugging using git-bisect(1), so
> I'd like to propose that bugfixes for (to-be-)released code are only
> applied on the 'maint' branch ('release' in the case of Notmuch),
> and then immediately merged back into 'master'.  In fact, this would
> preferrably happen after *every* (series of) commit(s) on the 'maint'
> branch, to prevent issues like [1].

There is some merit it to this. On the other hand, it makes the history
messier.  [1] would have also been prevented by making the patch against
the right branch.

[PATCH v4 2/5] cli: add support for replying just to the sender in "notmuch reply"

[Mark Walters]

LGTM

Best wishes

Mark

[PATCH] test: cli: getting/setting/removing config values

[David Bremner]

On Thu, 12 Jan 2012 18:30:01 +0100, Pieter Praet  wrote:
> Should have come before commit 1df71b55

This doesn't seem like an especially helpful commit
message. Editorializing is ok, I guess, but maybe keep it below the
'---' ?

d

[PATCH v4 5/5] test: add tests for "notmuch reply" --reply-to=sender

[Jani Nikula]

From: Mark Walters 

---
 test/notmuch-test|1 +
 test/reply-to-sender |  209 ++
 2 files changed, 210 insertions(+), 0 deletions(-)
 create mode 100755 test/reply-to-sender

diff --git a/test/notmuch-test b/test/notmuch-test
index e40ef86..6a99ae3 100755
--- a/test/notmuch-test
+++ b/test/notmuch-test
@@ -33,6 +33,7 @@ TESTS="
   thread-naming
   raw
   reply
+  reply-to-sender
   dump-restore
   uuencode
   thread-order
diff --git a/test/reply-to-sender b/test/reply-to-sender
new file mode 100755
index 000..c7d15bb
--- /dev/null
+++ b/test/reply-to-sender
@@ -0,0 +1,209 @@
+#!/usr/bin/env bash
+test_description="\"notmuch reply --reply-to=sender\" in several variations"
+. ./test-lib.sh
+
+test_begin_subtest "Basic reply-to-sender"
+add_message '[from]="Sender "' \
+ [to]=test_suite at notmuchmail.org \
+ [subject]=notmuch-reply-test \
+'[date]="Tue, 05 Jan 2010 15:43:56 -"' \
+'[body]="basic reply-to-sender test"'
+
+output=$(notmuch reply --reply-to=sender id:${gen_msg_id})
+test_expect_equal "$output" "From: Notmuch Test Suite 
+Subject: Re: notmuch-reply-test
+To: Sender 
+In-Reply-To: <${gen_msg_id}>
+References: <${gen_msg_id}>
+
+On Tue, 05 Jan 2010 15:43:56 -, Sender  wrote:
+> basic reply-to-sender test"
+
+test_begin_subtest "From Us, Basic reply to message"
+add_message '[from]="Notmuch Test Suite "' \
+'[to]="Recipient "' \
+ [subject]=notmuch-reply-test \
+'[date]="Tue, 05 Jan 2010 15:43:56 -"' \
+'[body]="basic reply-to-from-us test"'
+
+output=$(notmuch reply --reply-to=sender id:${gen_msg_id})
+test_expect_equal "$output" "From: Notmuch Test Suite 
+Subject: Re: notmuch-reply-test
+To: Recipient 
+In-Reply-To: <${gen_msg_id}>
+References: <${gen_msg_id}>
+
+On Tue, 05 Jan 2010 15:43:56 -, Notmuch Test Suite  wrote:
+> basic reply-to-from-us test"
+
+test_begin_subtest "Multiple recipients"
+add_message '[from]="Sender "' \
+'[to]="test_suite at notmuchmail.org, Someone Else "' \
+ [subject]=notmuch-reply-test \
+'[date]="Tue, 05 Jan 2010 15:43:56 -"' \
+'[body]="Multiple recipients"'
+
+output=$(notmuch reply  --reply-to=sender  id:${gen_msg_id})
+test_expect_equal "$output" "From: Notmuch Test Suite 
+Subject: Re: notmuch-reply-test
+To: Sender 
+In-Reply-To: <${gen_msg_id}>
+References: <${gen_msg_id}>
+
+On Tue, 05 Jan 2010 15:43:56 -, Sender  wrote:
+> Multiple recipients"
+
+test_begin_subtest "From Us, Multiple TO recipients"
+add_message '[from]="Notmuch Test Suite "' \
+'[to]="Recipient , Someone Else "' \
+ [subject]=notmuch-reply-test \
+'[date]="Tue, 05 Jan 2010 15:43:56 -"' \
+'[body]="From Us, Multiple TO recipients"'
+
+output=$(notmuch reply  --reply-to=sender  id:${gen_msg_id})
+test_expect_equal "$output" "From: Notmuch Test Suite 
+Subject: Re: notmuch-reply-test
+To: Recipient , Someone Else 
+In-Reply-To: <${gen_msg_id}>
+References: <${gen_msg_id}>
+
+On Tue, 05 Jan 2010 15:43:56 -, Notmuch Test Suite  wrote:
+> From Us, Multiple TO recipients"
+
+test_begin_subtest "Reply with CC"
+add_message '[from]="Sender "' \
+ [to]=test_suite at notmuchmail.org \
+'[cc]="Other Parties "' \
+ [subject]=notmuch-reply-test \
+'[date]="Tue, 05 Jan 2010 15:43:56 -"' \
+'[body]="reply with CC"'
+
+output=$(notmuch reply  --reply-to=sender id:${gen_msg_id})
+test_expect_equal "$output" "From: Notmuch Test Suite 
+Subject: Re: notmuch-reply-test
+To: Sender 
+In-Reply-To: <${gen_msg_id}>
+References: <${gen_msg_id}>
+
+On Tue, 05 Jan 2010 15:43:56 -, Sender  wrote:
+> reply with CC"
+
+test_begin_subtest "From Us, Reply with CC"
+add_message '[from]="Notmuch Test Suite "' \
+'[to]="Recipient "' \
+'[cc]="Other Parties "' \
+ [subject]=notmuch-reply-test \
+'[date]="Tue, 05 Jan 2010 15:43:56 -"' \
+'[body]="reply with CC"'
+
+output=$(notmuch reply  --reply-to=sender id:${gen_msg_id})
+test_expect_equal "$output" "From: Notmuch Test Suite 
+Subject: Re: notmuch-reply-test
+To: Recipient 
+In-Reply-To: <${gen_msg_id}>
+References: <${gen_msg_id}>
+
+On Tue, 05 Jan 2010 15:43:56 -, Notmuch Test Suite  wrote:
+> reply with CC"
+
+test_begin_subtest "From Us, Reply no TO but with CC"
+add_message '[from]="Notmuch Test Suite "' \
+'[cc]="Other Parties "' \
+ [subject]=notmuch-reply-test \
+'[date]="Tue, 05 Jan 2010 15:43:56 -"' \
+'[body]="reply with CC"'
+
+output=$(notmuch reply  --reply-to=sender id:${gen_msg_id})
+test_expect_equal "$output" "From: Notmuch Test Suite 
+Subject: Re: notmuch-reply-test
+Cc: Other Parties 
+In-Reply-To: <${gen_msg_id}>
+References: <${gen_msg_id}>
+
+On Tue, 05 Jan 

[PATCH v4 4/5] emacs: bind 'r' to reply-to-sender and 'R' to reply-to-all

[Jani Nikula]

Change the default reply key bindings, making 'r' reply-to-sender and 'R'
reply-to-all.

Signed-off-by: Jani Nikula 

---

There were mixed feelings about this. This as a separate patch so it's easy
to drop if needed.
---
 emacs/notmuch-show.el |4 ++--
 emacs/notmuch.el  |4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 96eea19..8f8ea93 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -932,8 +932,8 @@ thread id.  If a prefix is given, crypto processing is 
toggled."
(define-key map "s" 'notmuch-search)
(define-key map "m" 'notmuch-mua-new-mail)
(define-key map "f" 'notmuch-show-forward-message)
-   (define-key map "r" 'notmuch-show-reply)
-   (define-key map "R" 'notmuch-show-reply-sender)
+   (define-key map "r" 'notmuch-show-reply-sender)
+   (define-key map "R" 'notmuch-show-reply)
(define-key map "|" 'notmuch-show-pipe-message)
(define-key map "w" 'notmuch-show-save-attachments)
(define-key map "V" 'notmuch-show-view-raw-message)
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 9ac2888..d952c41 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -213,8 +213,8 @@ For a mouse binding, return nil."
 (define-key map ">" 'notmuch-search-last-thread)
 (define-key map "p" 'notmuch-search-previous-thread)
 (define-key map "n" 'notmuch-search-next-thread)
-(define-key map "r" 'notmuch-search-reply-to-thread)
-(define-key map "R" 'notmuch-search-reply-to-thread-sender)
+(define-key map "r" 'notmuch-search-reply-to-thread-sender)
+(define-key map "R" 'notmuch-search-reply-to-thread)
 (define-key map "m" 'notmuch-mua-new-mail)
 (define-key map "s" 'notmuch-search)
 (define-key map "o" 'notmuch-search-toggle-order)
-- 
1.7.5.4

[PATCH v4 3/5] emacs: add support for replying just to the sender

[Jani Nikula]

Provide reply to sender counterparts to the search and show reply
functions. Add key binding 'R' to reply to sender, while keeping 'r' as
reply to all, both in search and show views.

Signed-off-by: Jani Nikula 
---
 emacs/notmuch-mua.el  |9 ++---
 emacs/notmuch-show.el |   10 --
 emacs/notmuch.el  |9 -
 3 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index 32e2e30..d8ab822 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -71,12 +71,15 @@ list."
(push header message-hidden-headers)))
notmuch-mua-hidden-headers))

-(defun notmuch-mua-reply (query-string  sender)
+(defun notmuch-mua-reply (query-string  sender reply-all)
   (let (headers
body
(args '("reply")))
 (if notmuch-show-process-crypto
(setq args (append args '("--decrypt"
+(if reply-all
+   (setq args (append args '("--reply-to=all")))
+  (setq args (append args '("--reply-to=sender"
 (setq args (append args (list query-string)))
 ;; This make assumptions about the output of `notmuch reply', but
 ;; really only that the headers come first followed by a blank
@@ -218,13 +221,13 @@ the From: address first."
(notmuch-mua-forward-message))
 (notmuch-mua-forward-message)))

-(defun notmuch-mua-new-reply (query-string  prompt-for-sender)
+(defun notmuch-mua-new-reply (query-string  prompt-for-sender 
reply-all)
   "Invoke the notmuch reply window."
   (interactive "P")
   (let ((sender
 (when prompt-for-sender
   (notmuch-mua-prompt-for-sender
-(notmuch-mua-reply query-string sender)))
+(notmuch-mua-reply query-string sender reply-all)))

 (defun notmuch-mua-send-and-exit ( arg)
   (interactive "P")
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 5502efd..96eea19 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -933,6 +933,7 @@ thread id.  If a prefix is given, crypto processing is 
toggled."
(define-key map "m" 'notmuch-mua-new-mail)
(define-key map "f" 'notmuch-show-forward-message)
(define-key map "r" 'notmuch-show-reply)
+   (define-key map "R" 'notmuch-show-reply-sender)
(define-key map "|" 'notmuch-show-pipe-message)
(define-key map "w" 'notmuch-show-save-attachments)
(define-key map "V" 'notmuch-show-view-raw-message)
@@ -1237,9 +1238,14 @@ any effects from previous calls to
   (notmuch-show-previous-message)

 (defun notmuch-show-reply ( prompt-for-sender)
-  "Reply to the current message."
+  "Reply to the sender and all recipients of the current message."
   (interactive "P")
-  (notmuch-mua-new-reply (notmuch-show-get-message-id) prompt-for-sender))
+  (notmuch-mua-new-reply (notmuch-show-get-message-id) prompt-for-sender t))
+
+(defun notmuch-show-reply-sender ( prompt-for-sender)
+  "Reply to the sender of the current message."
+  (interactive "P")
+  (notmuch-mua-new-reply (notmuch-show-get-message-id) prompt-for-sender nil))

 (defun notmuch-show-forward-message ( prompt-for-sender)
   "Forward the current message."
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 1e61775..9ac2888 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -214,6 +214,7 @@ For a mouse binding, return nil."
 (define-key map "p" 'notmuch-search-previous-thread)
 (define-key map "n" 'notmuch-search-next-thread)
 (define-key map "r" 'notmuch-search-reply-to-thread)
+(define-key map "R" 'notmuch-search-reply-to-thread-sender)
 (define-key map "m" 'notmuch-mua-new-mail)
 (define-key map "s" 'notmuch-search)
 (define-key map "o" 'notmuch-search-toggle-order)
@@ -448,10 +449,16 @@ Complete list of currently available key bindings:
   (message "End of search results."

 (defun notmuch-search-reply-to-thread ( prompt-for-sender)
+  "Begin composing a reply-all to the entire current thread in a new buffer."
+  (interactive "P")
+  (let ((message-id (notmuch-search-find-thread-id)))
+(notmuch-mua-new-reply message-id prompt-for-sender t)))
+
+(defun notmuch-search-reply-to-thread-sender ( prompt-for-sender)
   "Begin composing a reply to the entire current thread in a new buffer."
   (interactive "P")
   (let ((message-id (notmuch-search-find-thread-id)))
-(notmuch-mua-new-reply message-id prompt-for-sender)))
+(notmuch-mua-new-reply message-id prompt-for-sender nil)))

 (defun notmuch-call-notmuch-process ( args)
   "Synchronously invoke \"notmuch\" with the given list of arguments.
-- 
1.7.5.4

[PATCH v4 2/5] cli: add support for replying just to the sender in "notmuch reply"

[Jani Nikula]

Add new option --reply-to=(all|sender) to "notmuch reply" to select whether
to reply to all (sender and all recipients), or just sender. Reply to all
remains the default.

Credits to Mark Walters  for his similar earlier
work where I picked up the basic idea of handling reply-to-sender in
add_recipients_from_message(). All bugs are mine, though.

Signed-off-by: Jani Nikula 

---

Settled on --reply-to=(all|sender) per Carl's earlier suggestion
(id:87pqn5cg4g.fsf at yoom.home.cworth.org) and David's approval on IRC.
---
 man/man1/notmuch-reply.1 |   28 
 notmuch-reply.c  |   52 +
 2 files changed, 65 insertions(+), 15 deletions(-)

diff --git a/man/man1/notmuch-reply.1 b/man/man1/notmuch-reply.1
index db464d8..5160ece 100644
--- a/man/man1/notmuch-reply.1
+++ b/man/man1/notmuch-reply.1
@@ -14,11 +14,13 @@ Constructs a reply template for a set of messages.
 To make replying to email easier,
 .B notmuch reply
 takes an existing set of messages and constructs a suitable mail
-template. The Reply-to header (if any, otherwise From:) is used for
-the To: address. Vales from the To: and Cc: headers are copied, but
-not including any of the current user's email addresses (as configured
-in primary_mail or other_email in the .notmuch\-config file) in the
-recipient list
+template. The Reply-to: header (if any, otherwise From:) is used for
+the To: address. Unless
+.BR \-\-reply-to=sender
+is specified, values from the To: and Cc: headers are copied, but not
+including any of the current user's email addresses (as configured in
+primary_mail or other_email in the .notmuch\-config file) in the
+recipient list.

 It also builds a suitable new subject, including Re: at the front (if
 not already present), and adding the message IDs of the messages being
@@ -45,6 +47,22 @@ Includes subject and quoted message body.
 Only produces In\-Reply\-To, References, To, Cc, and Bcc headers.
 .RE
 .RE
+.RS
+.TP 4
+.BR \-\-reply\-to= ( all | sender )
+.RS
+.TP 4
+.BR all " (default)"
+Replies to all addresses.
+.TP 4
+.BR sender
+Replies only to the sender. If replying to user's own message
+(Reply-to: or From: header is one of the user's configured email
+addresses), try To:, Cc:, and Bcc: headers in this order, and copy
+values from the first that contains something other than only the
+user's addresses.
+.RE
+.RE

 See \fBnotmuch-search-terms\fR(7)
 for details of the supported syntax for .
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 4fae66f..b4c81de 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -289,7 +289,14 @@ reply_to_header_is_redundant (notmuch_message_t *message)
 return 0;
 }

-/* Augments the recipients of reply from the headers of message.
+/* Augment the recipients of 'reply' from the "Reply-to:", "From:", "To:",
+ * "Cc:", and "Bcc:" headers of 'message'.
+ *
+ * If 'reply_all' is true, use sender and all recipients, otherwise scan the
+ * headers for the first that contains something other than the user's 
addresses
+ * and add the recipients from this header (typically this would be
+ * reply-to-sender, but also handles reply to user's own message in a sensible
+ * way).
  *
  * If any of the user's addresses were found in these headers, the first
  * of these returned, otherwise NULL is returned.
@@ -297,7 +304,8 @@ reply_to_header_is_redundant (notmuch_message_t *message)
 static const char *
 add_recipients_from_message (GMimeMessage *reply,
 notmuch_config_t *config,
-notmuch_message_t *message)
+notmuch_message_t *message,
+notmuch_bool_t reply_all)
 {
 struct {
const char *header;
@@ -311,6 +319,7 @@ add_recipients_from_message (GMimeMessage *reply,
 };
 const char *from_addr = NULL;
 unsigned int i;
+unsigned int n = 0;

 /* Some mailing lists munge the Reply-To header despite it being A Bad
  * Thing, see http://www.unicom.com/pw/reply-to-harmful.html
@@ -337,8 +346,23 @@ add_recipients_from_message (GMimeMessage *reply,
recipients = notmuch_message_get_header (message,
 reply_to_map[i].fallback);

-   scan_address_string (recipients, config, reply,
-reply_to_map[i].recipient_type, _addr);
+   n += scan_address_string (recipients, config, reply,
+ reply_to_map[i].recipient_type, _addr);
+
+   if (!reply_all && n) {
+   /* Stop adding new recipients in reply-to-sender mode if we have
+* added some recipient(s) above.
+*
+* This also handles the case of user replying to his own message,
+* where reply-to/from is not a recipient. In this case there may be
+* more than one recipient even if not replying to all.
+*/
+   reply = NULL;
+
+   /* 

[PATCH v4 1/5] cli: slightly refactor "notmuch reply" address scanning functions

[Jani Nikula]

Slightly refactor "notmuch reply" recipient and user from address scanning
functions in preparation for reply-to-sender feature.

Add support for not adding messages at all (just scan for user from
address), and returning the number of messages added.

No externally visible functional changes.

Signed-off-by: Jani Nikula 
---
 notmuch-reply.c |   74 --
 1 files changed, 38 insertions(+), 36 deletions(-)

diff --git a/notmuch-reply.c b/notmuch-reply.c
index 000f6da..4fae66f 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -168,22 +168,28 @@ address_is_users (const char *address, notmuch_config_t 
*config)
 return 0;
 }

-/* For each address in 'list' that is not configured as one of the
- * user's addresses in 'config', add that address to 'message' as an
- * address of 'type'.
+/* Scan addresses in 'list'.
  *
- * The first address encountered that *is* the user's address will be
- * returned, (otherwise NULL is returned).
+ * If 'message' is non-NULL, then for each address in 'list' that is not
+ * configured as one of the user's addresses in 'config', add that address to
+ * 'message' as an address of 'type'.
+ *
+ * If 'user_from' is non-NULL and *user_from is NULL, the first address
+ * encountered in 'list' that *is* the user's address will be set to 
*user_from.
+ *
+ * Return the number of addresses added to 'message'. (If 'message' is NULL, 
the
+ * function returns 0 by definition.)
  */
-static const char *
-add_recipients_for_address_list (GMimeMessage *message,
-notmuch_config_t *config,
-GMimeRecipientType type,
-InternetAddressList *list)
+static unsigned int
+scan_address_list (InternetAddressList *list,
+  notmuch_config_t *config,
+  GMimeMessage *message,
+  GMimeRecipientType type,
+  const char **user_from)
 {
 InternetAddress *address;
 int i;
-const char *ret = NULL;
+unsigned int n = 0;

 for (i = 0; i < internet_address_list_length (list); i++) {
address = internet_address_list_get_address (list, i);
@@ -196,8 +202,7 @@ add_recipients_for_address_list (GMimeMessage *message,
if (group_list == NULL)
continue;

-   add_recipients_for_address_list (message, config,
-type, group_list);
+   n += scan_address_list (group_list, config, message, type, NULL);
} else {
InternetAddressMailbox *mailbox;
const char *name;
@@ -209,40 +214,40 @@ add_recipients_for_address_list (GMimeMessage *message,
addr = internet_address_mailbox_get_addr (mailbox);

if (address_is_users (addr, config)) {
-   if (ret == NULL)
-   ret = addr;
-   } else {
+   if (user_from && *user_from == NULL)
+   *user_from = addr;
+   } else if (message) {
g_mime_message_add_recipient (message, type, name, addr);
+   n++;
}
}
 }

-return ret;
+return n;
 }

-/* For each address in 'recipients' that is not configured as one of
- * the user's addresses in 'config', add that address to 'message' as
- * an address of 'type'.
+/* Scan addresses in 'recipients'.
  *
- * The first address encountered that *is* the user's address will be
- * returned, (otherwise NULL is returned).
+ * See the documentation of scan_address_list() above. This function does
+ * exactly the same, but converts 'recipients' to an InternetAddressList first.
  */
-static const char *
-add_recipients_for_string (GMimeMessage *message,
-  notmuch_config_t *config,
-  GMimeRecipientType type,
-  const char *recipients)
+static unsigned int
+scan_address_string (const char *recipients,
+notmuch_config_t *config,
+GMimeMessage *message,
+GMimeRecipientType type,
+const char **user_from)
 {
 InternetAddressList *list;

 if (recipients == NULL)
-   return NULL;
+   return 0;

 list = internet_address_list_parse_string (recipients);
 if (list == NULL)
-   return NULL;
+   return 0;

-return add_recipients_for_address_list (message, config, type, list);
+return scan_address_list (list, config, message, type, user_from);
 }

 /* Does the address in the Reply-To header of 'message' already appear
@@ -324,7 +329,7 @@ add_recipients_from_message (GMimeMessage *reply,
 }

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

recipients = notmuch_message_get_header (message,
 reply_to_map[i].header);
@@ -332,11 +337,8 @@ 

[PATCH v4 0/5] reply to sender

[Jani Nikula]

Hi all, changes since v3:

Split the first patch into two, the first one refactoring the reply/from address
scanning, and the second one adding the actual reply-to-sender feature. This
addresses Austins comments in id:"20120112033146.GU20796 at mit.edu" (and does
improve the code).

Patches 3-5 remain unchanged.


BR,
Jani.


Jani Nikula (4):
  cli: slightly refactor "notmuch reply" address scanning functions
  cli: add support for replying just to the sender in "notmuch reply"
  emacs: add support for replying just to the sender
  emacs: bind 'r' to reply-to-sender and 'R' to reply-to-all

Mark Walters (1):
  test: add tests for "notmuch reply" --reply-to=sender

 emacs/notmuch-mua.el |9 ++-
 emacs/notmuch-show.el|   12 ++-
 emacs/notmuch.el |   11 ++-
 man/man1/notmuch-reply.1 |   28 +-
 notmuch-reply.c  |  122 +--
 test/notmuch-test|1 +
 test/reply-to-sender |  209 ++
 7 files changed, 335 insertions(+), 57 deletions(-)
 create mode 100755 test/reply-to-sender

-- 
1.7.5.4

[PATCH v2] emacs: logically group def{custom,face}s

[David Bremner]

On Thu, 12 Jan 2012 18:12:16 +0100, Pieter Praet  wrote:
> To allow for expansion whilst keeping everything tidy and organized,
> move all defcustom/defface variables to the following subgroups,
> defined in notmuch-lib.el:
> 
> - Hello
> - Search
> - Show
> - Send
> - Crypto
> - Hooks
> - Appearance
> - External Commands

I didn't investigate too closely, but I noticed when I customize-group
emacs, each subgroup has some explanatory text beside it. Did you omit
that on purpose?

d

[PATCH v4 1/5] cli: slightly refactor "notmuch reply" address scanning functions

[Mark Walters]

This is nice.

Two very minor nits:

In your commit message you say

> Add support for not adding messages at all (just scan for user from
> address), and returning the number of messages added.

and I think both "messages" should "recipients".

> + * If 'user_from' is non-NULL and *user_from is NULL, the first address
> + * encountered in 'list' that *is* the user's address will be set to 
> *user_from.

This reads oddly: you are setting *user_from to the first address...
(rather than the other way round)

Best wishes

Mark

[PATCH v2] Output unmodified Content-Type header value for JSON format.

[David Bremner]

On Thu, 12 Jan 2012 18:08:08 +0100, Pieter Praet  wrote:
> > > - The previous point is a bit of a counterargument to this, but in

> > I couls separate it.  I made is a single patch to avoid having a
> > revision with broken emacs UI (and tests).
> > 

> I'd like to propose to always apply patch series on a *topic* branch
> which would then be merged back into 'master', thus avoiding this issue
> altogether whilst making it more obvious which patches belong together
> (eg. for easier cross-referencing with the ML).

Hi Pieter;

Sorry, I must have lost the thread somewhere.  What application are you
thinking about, and what issue do you think that topic branches avoid?

d

0.11 is frozen, please update NEWS

[Xavier Maillard]

Hi,

Maybe it is inappropriate, but do you have any idea when you plan to
release the so-expected 0.11 release ? 

Anyway, keep up the good job guys !

/Xavier

[PATCH 2/2] NEWS: fix some old typos and trailing whitespace

[David Bremner]

On Thu, 12 Jan 2012 18:06:14 +0100, Pieter Praet  wrote:
> That would indeed have been the most sensible thing to do.
> 
> Could someone (who -unlike me- has already submitted his/her public SSH
> key for commit access) add something along those lines to the Patch
> Formatting guidelines [1] ?  Perhaps just quote Carl's statement [2] ?
> 

Hi Pieter;

It's a wiki, anyone can push.

d

[PATCH] emacs: globally replace non-branching "(if (not ..." with "(unless ..."

[Xavier Maillard]

On Thu, 12 Jan 2012 18:33:06 +0100, Pieter Praet  wrote:
> Less code, same results, without sacrificing readability.

+1

/Xavier

[PATCH] emacs: whitespace-cleanup for emacs/*.el files

[Xavier Maillard]

On Wed, 11 Jan 2012 17:13:35 +0200, Tomi Ollila  wrote:
> Executed
> for f in emacs/*.el
> do emacs -q --batch --eval \
> "(progn (find-file \"$f\") (whitespace-cleanup) (save-buffer))"
> done
> 
> which
> removed trailing whitespace and empty lines at the end of file
> removed spaces before tab (if any)
> converted 8 spaces to tabs in the beginning of line

+1

Maybe we should note something about this as a /coding style/ rule ?

/Xavier

[PATCH v2] emacs: Helpers for notmuch developers.

[David Bremner]

On Mon, 09 Jan 2012 11:16:20 +, David Edmondson  wrote:
> On Mon, 09 Jan 2012 06:38:54 -0400, David Bremner  
> wrote:
> Could you try running
>   (notmuch-dev-delete-branch 
> "review/patch-emacs-don't-signal-an-error-when-reaching-the-end-of-the-search-results")
> when inside that repository please?

Sorry for the delay.

zancas:/tmp/notmuch-dev-bremner  (git)-[master]-% git branch   
* master
  
review/patch-emacs-don't-signal-an-error-when-reaching-the-end-of-the-search-results

It looks likes somebody needs to use git branch -D?




Debugger entered--Lisp error: (error "The branch 
'review/patch-emacs-don't-signal-an-error-when-reaching-the-end-of-the-search-results'
 is not fully merged.")
  signal(error ("The branch 
'review/patch-emacs-don't-signal-an-error-when-reaching-the-end-of-the-search-results'
 is not fully merged."))
  error("The branch 
'review/patch-emacs-don't-signal-an-error-when-reaching-the-end-of-the-search-results'
 is not fully merged.")
  magit-run*(("git" "--no-pager" "branch" "-d" 
"review/patch-emacs-don't-signal-an-error-when-reaching-the-end-of-the-search-results"))
  #[nil "\303\304  B\n\"!\207" [magit-git-executable 
magit-git-standard-options args magit-run* append] 4]()
  magit-refresh-wrapper(#[nil "\303\304B\n\"!\207" 
[magit-git-executable magit-git-standard-options args magit-run* append] 4])
  magit-run-git("branch" "-d" 
"review/patch-emacs-don't-signal-an-error-when-reaching-the-end-of-the-search-results")
  
magit-delete-branch("review/patch-emacs-don't-signal-an-error-when-reaching-the-end-of-the-search-results")
  
notmuch-dev-delete-branch("review/patch-emacs-don't-signal-an-error-when-reaching-the-end-of-the-search-results")
  eval((notmuch-dev-delete-branch 
"review/patch-emacs-don't-signal-an-error-when-reaching-the-end-of-the-search-results"))
  eval-last-sexp-1(nil)

[PATCH] emacs: Improve `notmuch-hello' display on ttys.

[David Bremner]

On Tue, 10 Jan 2012 10:15:28 +, David Edmondson  wrote:
> Inserting spaces to pad out columns is good, except when the padding
> makes the line wider than the window. This looks particularly bad on a
> tty where there is no fringe.

Pushed, 

d

[PATCH] emacs: globally replace non-branching "(if (not ..." with "(unless ..."

[Dmitry Kurochkin]

On Thu, 12 Jan 2012 18:33:06 +0100, Pieter Praet  wrote:
> Less code, same results, without sacrificing readability.
> 

+1

Regards,
  Dmitry

> ---
>  emacs/notmuch-address.el |6 +++---
>  emacs/notmuch-hello.el   |   20 ++--
>  emacs/notmuch-show.el|   12 ++--
>  emacs/notmuch.el |8 
>  4 files changed, 23 insertions(+), 23 deletions(-)
> 
> diff --git a/emacs/notmuch-address.el b/emacs/notmuch-address.el
> index 8eba7a0..d72b169 100644
> --- a/emacs/notmuch-address.el
> +++ b/emacs/notmuch-address.el
> @@ -37,9 +37,9 @@ line."
>  (defvar notmuch-address-history nil)
>  
>  (defun notmuch-address-message-insinuate ()
> -  (if (not (memq notmuch-address-message-alist-member 
> message-completion-alist))
> -  (setq message-completion-alist
> - (push notmuch-address-message-alist-member 
> message-completion-alist
> +  (unless (memq notmuch-address-message-alist-member 
> message-completion-alist)
> +(setq message-completion-alist
> +   (push notmuch-address-message-alist-member 
> message-completion-alist
>  
>  (defun notmuch-address-options (original)
>(process-lines notmuch-address-command original))
> diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
> index 333d4c1..dce2020 100644
> --- a/emacs/notmuch-hello.el
> +++ b/emacs/notmuch-hello.el
> @@ -315,7 +315,7 @@ should be. Returns a cons cell `(tags-per-line width)'."
>  
>  ;; If the last line was not full (and hence did not include a
>  ;; carriage return), insert one now.
> -(if (not (eq (% count tags-per-line) 0))
> +(unless (eq (% count tags-per-line) 0)
>   (widget-insert "\n"))
>  found-target-pos))
>  
> @@ -399,7 +399,7 @@ Complete list of currently available key bindings:
>  
>; Jump through a hoop to get this value from the deprecated variable
>; name (`notmuch-folders') or from the default value.
> -  (if (not notmuch-saved-searches)
> +  (unless notmuch-saved-searches
>  (setq notmuch-saved-searches (notmuch-saved-searches)))
>  
>(if no-display
> @@ -565,18 +565,18 @@ Complete list of currently available key bindings:
> (widget-insert "\n\n")
> (let ((start (point)))
>   (setq found-target-pos (notmuch-hello-insert-tags alltags-alist 
> widest target))
> - (if (not final-target-pos)
> - (setq final-target-pos found-target-pos))
> + (unless final-target-pos
> +   (setq final-target-pos found-target-pos))
>   (indent-rigidly start (point) notmuch-hello-indent)))
>  
>   (widget-insert "\n")
>  
> - (if (not notmuch-show-all-tags-list)
> - (widget-create 'push-button
> -:notify (lambda (widget  ignore)
> -  (setq notmuch-show-all-tags-list t)
> -  (notmuch-hello-update))
> -"Show all tags")))
> + (unless notmuch-show-all-tags-list
> +   (widget-create 'push-button
> +  :notify (lambda (widget  ignore)
> +(setq notmuch-show-all-tags-list t)
> +(notmuch-hello-update))
> +  "Show all tags")))
>  
>(let ((start (point)))
>   (widget-insert "\n\n")
> diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
> index 5502efd..d3543f0 100644
> --- a/emacs/notmuch-show.el
> +++ b/emacs/notmuch-show.el
> @@ -659,8 +659,8 @@ current buffer, if possible."
>;; part, so we make sure that we're down at the end.
>(goto-char (point-max))
>;; Ensure that the part ends with a carriage return.
> -  (if (not (bolp))
> -  (insert "\n")))
> +  (unless (bolp)
> +(insert "\n")))
>  
>  (defun notmuch-show-insert-body (msg body depth)
>"Insert the body BODY at depth DEPTH in the current thread."
> @@ -740,8 +740,8 @@ current buffer, if possible."
>  (setq body-start (point-marker))
>  (notmuch-show-insert-body msg (plist-get msg :body) depth)
>  ;; Ensure that the body ends with a newline.
> -(if (not (bolp))
> - (insert "\n"))
> +(unless (bolp)
> +  (insert "\n"))
>  (setq body-end (point-marker))
>  (setq content-end (point-marker))
>  
> @@ -882,8 +882,8 @@ buffer."
>(run-hooks 'notmuch-show-hook))
>  
>  ;; Move straight to the first open message
> -(if (not (notmuch-show-message-visible-p))
> - (notmuch-show-next-open-message))
> +(unless (notmuch-show-message-visible-p)
> +  (notmuch-show-next-open-message))
>  
>  ;; Set the header line to the subject of the first open message.
>  (setq header-line-format (notmuch-show-strip-re 
> (notmuch-show-get-subject)))
> diff --git a/emacs/notmuch.el b/emacs/notmuch.el
> index 1e61775..ba84494 100644
> --- a/emacs/notmuch.el
> +++ b/emacs/notmuch.el
> @@ -636,8 +636,8 @@ This function advances the next thread when finished."
>   (if 

[PATCH] test: don't bail out of `run_emacs' too early when missing prereqs

[Dmitry Kurochkin]

On Thu, 12 Jan 2012 18:16:59 +0100, Pieter Praet  wrote:
> When running the Emacs tests in verbose mode, only the first missing
> prereq is reported because the `run_emacs' function is short-circuited
> early:
> 
>   #+begin_example
> emacs: Testing emacs interface
>  missing prerequisites: [0]  emacs(1)
>  skipping test: [0]  Basic notmuch-hello view in emacs
>  SKIP   [0]  Basic notmuch-hello view in emacs
>   #+end_example
> 
> This can lead to situations reminiscent of "dependency hell", so instead
> of returning based on each individual `test_require_external_prereq's exit
> status, we now do so by checking $test_subtest_missing_external_prereqs_:
> 
>   #+begin_example
> emacs: Testing emacs interface
>  missing prerequisites: [0]  dtach(1) emacs(1) emacsclient(1)
>  skipping test: [0]  Basic notmuch-hello view in emacs
>  SKIP   [0]  Basic notmuch-hello view in emacs
>   #+end_example
> 
> Also add missing prereq for dtach(1).
> 
> ---
>  test/test-lib.sh |6 --
>  1 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/test/test-lib.sh b/test/test-lib.sh
> index 82767c0..6ec3882 100644
> --- a/test/test-lib.sh
> +++ b/test/test-lib.sh
> @@ -907,8 +907,10 @@ EOF
>  
>  test_emacs () {
>   # test dependencies beforehand to avoid the waiting loop below
> - test_require_external_prereq emacs || return
> - test_require_external_prereq emacsclient || return
> + test_require_external_prereq dtach
> + test_require_external_prereq emacs
> + test_require_external_prereq emacsclient
> + test -z "$test_subtest_missing_external_prereqs_" || return

There may be other missing dependencies before test_emacs() is called
and $test_subtest_missing_external_prereqs_ would not be blank.  Also, I
would like to keep the number of functions that use
$test_subtest_missing_external_prereqs_ minimal.  How about:

  missing_dependencies=
  test_require_... dtach || missing_dependencies=1
  test_require_... emacs || missing_dependencies=1
  ...
  test -z "$missing_dependencies" || return

Regards,
  Dmitry

>  
>   if [ -z "$EMACS_SERVER" ]; then
>   server_name="notmuch-test-suite-$$"
> -- 
> 1.7.8.1
> 

Emacs: Crypto: How to get automatic encryption?

[Gregor Zattler]

Hi Jameson,
* Jameson Graef Rollins  [12. Jan. 2012]:
> On Tue, 03 Jan 2012 13:45:14 -0800, Jameson Graef Rollins  finestructure.net> wrote:
>> Unfortunately, auto encrypting of replies to encrypted emails is not yet
>> implemented.  It is desperately needed, though, obviously.  So this is a
>> good excuse to start a discussion about how we could achieve this.
[...]
> There is a set of patches in the queue to add a JSON output format for
> reply, with the emacs UI then consuming that to construct the reply
> template [0].  This will make it very easy to communicate to the emacs
> UI that the original message was encrypted, and that the reply should be
> similarly encrypted.  I'm going to wait until that patch set makes it
> through, and then build this functionality on top of that.
> [0] id:"1326009162-19524-3-git-send-email-awg+notmuch at xvx.ca"


That would be really great.

But how about not only replying encrypted but encrypting every
email if possible?  "Possible" could mean different things,
though:

1) encrypt if fully trusted suitable public keys for all
   recipients are GnuPG key ring.

2) encrypt if suitable public keys for all recipients are in
   GnuPGs key ring.

3) try to fetch suitable public keys from server in order to to
   check 2).


I for instance fiddled with my mutt configuration to achieve 1).

But I have no clue about how to do this with notmuch/Emacs.

Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-

Emacs: Crypto: How to get automatic encryption?

[Darren McGuicken]

On Thu, 12 Jan 2012 20:05:14 +0100, Gregor Zattler  wrote:
> 2) encrypt if suitable public keys for all recipients are in
>GnuPGs key ring.
[...]
> But I have no clue about how to do this with notmuch/Emacs.

Isn't that what David provides an elisp-snippet for in
id:"cunk4576ezs.fsf at hotblack-desiato.hh.sledj.net"?

I've been using it myself since it was posted and it seems to work
according to the behaviour you desire in point 2.
-- 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/20120112/2519662c/attachment.pgp>

[PATCH v2] notmuch/emacs: Observe the charset of text/html parts, where known.

[David Edmondson]

On Thu, 12 Jan 2012 13:49:59 -0500, Austin Clements  wrote:
> Quoth David Edmondson on Jan 12 at  1:31 pm:
> > Add the charset of text/html parts to the JSON output of 'notmuch
> > -show' when it is known. Observe the encoding when rendering such
> > parts in emacs.
> 
> This seems like a fine interim solution to me, though I'd like to see
> a comment above the change in format_part_content_json explaining why
> we include the content charset for text/html and not for anything
> else.

Okay, thanks. New patch tomorrow.
-- 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/20120112/785a16bd/attachment-0001.pgp>

[PATCH] notmuch/emacs: Observe the charset of encoded parts, where known.

[Dmitry Kurochkin]

On Thu, 12 Jan 2012 14:42:49 +, David Edmondson  wrote:
> On Thu, 12 Jan 2012 18:17:44 +0400, Dmitry Kurochkin  gmail.com> wrote:
> > I think there is a record of useful features and fixes that were not
> > accepted to notmuch because of some implementation issues.  And
> > interested people were using them in private repos for years.  (I do not
> > say that it is always the right thing to do, or that it is the right
> > thing in this particular case.)
> 
> I agree that this has happened. I think that it's a failure of the
> project that it has become common, necessary and generally accepted.
> 
> > I would like to see the following changes:
> > 
> > * Properly handle charset with parameters in Emacs UI.  Currently it is
> >   broken by your patch in one place at least:
> >   `notmuch-show-handlers-for' would produce incorrect results for
> >   content-type string with parameters.  In my patch [1] I did parse the
> >   charset at top level and then changed all usages of it accordingly.
> >   Making `notmuch-show-handlers-for' smarter about parameters may be
> >   sufficient, but I would like to see some more details on why adding
> >   parameters to content-type string does not break Emacs UI code in
> >   other places.
> 
> Your patch modifies the output of 'notmuch show' such that it included
> the full value of the content-type header, which means that it is
> necessary to parse it more carefully in emacs to discover and (as
> necessary) remove the parameters. The patch I posted doesn't do this,
> preferring to pass the charset (if any) as a supplementary parameter and
> leave the content-type as-is. This distinction means that the patch I
> posted isn't broken in the way that you describe.
> 

Sorry, I should have better look at the code.

> > * Add charset parameter for text/html parts only.
> 
> Version 2 of the patch does this.
> 
> > * Use `mail-header-parse-content-type' to parse content-type instead of
> >   contructing the list for `mm-make-handle' manually.
> 
> That's not required, see above.
> 
> > * Add a proper XXX comment to notmuch-show code.
> 
> I'm happy to do that.
> 
> > I cannot say I would be happy about this patch after these changes.
> 
> Can you say why? I agree that it is not a solution to all problems, but
> it is a workable solution to a specific problem.
> 

At the very least, because I did not really review the code, as you
probably understood from my poor comments :)

I do not have a strong preference here.  If others do, I prefer to leave
it for them to decide.

> > It would be a temporary hack anyway.
> 
> Agreed. Do you have any idea when you might be able to spend time on the
> better approach?

I hope to work on this once Austin's notmuch show rewrite is done.  It
is progressing, but I do not have any estimations.

Regards,
  Dmitry

[PATCH] emacs: globally replace non-branching "(if (not ..." with "(unless ..."

[Pieter Praet]

Less code, same results, without sacrificing readability.

---
 emacs/notmuch-address.el |6 +++---
 emacs/notmuch-hello.el   |   20 ++--
 emacs/notmuch-show.el|   12 ++--
 emacs/notmuch.el |8 
 4 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/emacs/notmuch-address.el b/emacs/notmuch-address.el
index 8eba7a0..d72b169 100644
--- a/emacs/notmuch-address.el
+++ b/emacs/notmuch-address.el
@@ -37,9 +37,9 @@ line."
 (defvar notmuch-address-history nil)

 (defun notmuch-address-message-insinuate ()
-  (if (not (memq notmuch-address-message-alist-member 
message-completion-alist))
-  (setq message-completion-alist
-   (push notmuch-address-message-alist-member 
message-completion-alist
+  (unless (memq notmuch-address-message-alist-member message-completion-alist)
+(setq message-completion-alist
+ (push notmuch-address-message-alist-member 
message-completion-alist

 (defun notmuch-address-options (original)
   (process-lines notmuch-address-command original))
diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index 333d4c1..dce2020 100644
--- a/emacs/notmuch-hello.el
+++ b/emacs/notmuch-hello.el
@@ -315,7 +315,7 @@ should be. Returns a cons cell `(tags-per-line width)'."

 ;; If the last line was not full (and hence did not include a
 ;; carriage return), insert one now.
-(if (not (eq (% count tags-per-line) 0))
+(unless (eq (% count tags-per-line) 0)
(widget-insert "\n"))
 found-target-pos))

@@ -399,7 +399,7 @@ Complete list of currently available key bindings:

   ; Jump through a hoop to get this value from the deprecated variable
   ; name (`notmuch-folders') or from the default value.
-  (if (not notmuch-saved-searches)
+  (unless notmuch-saved-searches
 (setq notmuch-saved-searches (notmuch-saved-searches)))

   (if no-display
@@ -565,18 +565,18 @@ Complete list of currently available key bindings:
  (widget-insert "\n\n")
  (let ((start (point)))
(setq found-target-pos (notmuch-hello-insert-tags alltags-alist 
widest target))
-   (if (not final-target-pos)
-   (setq final-target-pos found-target-pos))
+   (unless final-target-pos
+ (setq final-target-pos found-target-pos))
(indent-rigidly start (point) notmuch-hello-indent)))

(widget-insert "\n")

-   (if (not notmuch-show-all-tags-list)
-   (widget-create 'push-button
-  :notify (lambda (widget  ignore)
-(setq notmuch-show-all-tags-list t)
-(notmuch-hello-update))
-  "Show all tags")))
+   (unless notmuch-show-all-tags-list
+ (widget-create 'push-button
+:notify (lambda (widget  ignore)
+  (setq notmuch-show-all-tags-list t)
+  (notmuch-hello-update))
+"Show all tags")))

   (let ((start (point)))
(widget-insert "\n\n")
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 5502efd..d3543f0 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -659,8 +659,8 @@ current buffer, if possible."
   ;; part, so we make sure that we're down at the end.
   (goto-char (point-max))
   ;; Ensure that the part ends with a carriage return.
-  (if (not (bolp))
-  (insert "\n")))
+  (unless (bolp)
+(insert "\n")))

 (defun notmuch-show-insert-body (msg body depth)
   "Insert the body BODY at depth DEPTH in the current thread."
@@ -740,8 +740,8 @@ current buffer, if possible."
 (setq body-start (point-marker))
 (notmuch-show-insert-body msg (plist-get msg :body) depth)
 ;; Ensure that the body ends with a newline.
-(if (not (bolp))
-   (insert "\n"))
+(unless (bolp)
+  (insert "\n"))
 (setq body-end (point-marker))
 (setq content-end (point-marker))

@@ -882,8 +882,8 @@ buffer."
   (run-hooks 'notmuch-show-hook))

 ;; Move straight to the first open message
-(if (not (notmuch-show-message-visible-p))
-   (notmuch-show-next-open-message))
+(unless (notmuch-show-message-visible-p)
+  (notmuch-show-next-open-message))

 ;; Set the header line to the subject of the first open message.
 (setq header-line-format (notmuch-show-strip-re 
(notmuch-show-get-subject)))
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 1e61775..ba84494 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -636,8 +636,8 @@ This function advances the next thread when finished."
(if notmuch-search-process-filter-data
(insert (concat "Error: Unexpected output from 
notmuch search:\n" notmuch-search-process-filter-data)))
(insert "End of search results.")
-   (if (not (= exit-status 0))
-   

[PATCH v3] emacs: support "notmuch new" as a notmuch-poll-script

[Pieter Praet]

On Mon, 12 Dec 2011 22:50:04 +0200, Jani Nikula  wrote:
> Support nil value for notmuch-poll-script to run "notmuch new" instead of
> an external script, and make this the new default. "notmuch new" is run
> using the configured notmuch-command.
> 
> This allows taking better advantage of the "notmuch new" hooks from emacs
> without intermediate scripts.
> 
> Signed-off-by: Jani Nikula 
> 
> ---
> 
> v3: only documentation changes suggested by Austin and Dmitry.
> ---
>  emacs/notmuch.el |   35 +--
>  1 files changed, 25 insertions(+), 10 deletions(-)
> 
> diff --git a/emacs/notmuch.el b/emacs/notmuch.el
> index 8936149..675a110 100644
> --- a/emacs/notmuch.el
> +++ b/emacs/notmuch.el
> @@ -965,28 +965,43 @@ same relative position within the new buffer."
>  (notmuch-search query oldest-first target-thread target-line 
> continuation)
>  (goto-char (point-min
>  
> -(defcustom notmuch-poll-script ""
> +(defcustom notmuch-poll-script nil
>"An external script to incorporate new mail into the notmuch database.
>  
> -If this variable is non empty, then it should name a script to be
> -invoked by `notmuch-search-poll-and-refresh-view' and
> +This variable controls the action invoked by
> +`notmuch-search-poll-and-refresh-view' and
>  `notmuch-hello-poll-and-update' (each have a default keybinding
> -of 'G'). The script could do any of the following depending on
> +of 'G') to incorporate new mail into the notmuch database.
> +
> +If set to nil (the default), new mail is processed by invoking
> +\"notmuch new\". Otherwise, this should be set to a string that
> +gives the name of an external script that processes new mail. If
> +set to the empty string, no command will be run.
> +
> +The external script could do any of the following depending on
>  the user's needs:
>  
>  1. Invoke a program to transfer mail to the local mail store
>  2. Invoke \"notmuch new\" to incorporate the new mail
> -3. Invoke one or more \"notmuch tag\" commands to classify the mail"
> -  :type 'string
> +3. Invoke one or more \"notmuch tag\" commands to classify the mail
> +
> +Note that the recommended way of achieving the same is using
> +\"notmuch new\" hooks."
> +  :type '(choice (const :tag "notmuch new" nil)
> +  (const :tag "Disabled" "")
> +  (string :tag "Custom script"))
>:group 'notmuch)
>  
>  (defun notmuch-poll ()
> -  "Run external script to import mail.
> +  "Run \"notmuch new\" or an external script to import mail.
>  
> -Invokes `notmuch-poll-script' if it is not set to an empty string."
> +Invokes `notmuch-poll-script', \"notmuch new\", or does nothing
> +depending on the value of `notmuch-poll-script'."
>(interactive)
> -  (if (not (string= notmuch-poll-script ""))
> -  (call-process notmuch-poll-script nil nil)))
> +  (if (stringp notmuch-poll-script)
> +  (if (not (string= notmuch-poll-script ""))
> +   (call-process notmuch-poll-script nil nil))
> +(call-process notmuch-command nil nil nil "new")))

Since it seems to be bikeshedding-season:

When `(if (not's don't have an `else'-part, use `unless' instead ?

Patch follows.

>  
>  (defun notmuch-search-poll-and-refresh-view ()
>"Invoke `notmuch-poll' to import mail, then refresh the current view."
> -- 
> 1.7.5.4
> 
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch


Nicely complements the new hooks (for which thanks) !


Peace

-- 
Pieter

[PATCH] test: cli: getting/setting/removing config values

[Pieter Praet]

Should have come before commit 1df71b55

---
 test/config   |   88 +
 test/notmuch-test |1 +
 2 files changed, 89 insertions(+), 0 deletions(-)
 create mode 100755 test/config

diff --git a/test/config b/test/config
new file mode 100755
index 000..ee3126c
--- /dev/null
+++ b/test/config
@@ -0,0 +1,88 @@
+#!/usr/bin/env bash
+test_description='notmuch config'
+. ./test-lib.sh
+
+
+config_options=(
+"database.path"
+"user.name"
+"user.primary_email"
+"user.other_email"
+"new.tags"
+"maildir.synchronize_flags"
+)
+
+
+test_begin_subtest 'getting config: "config get ."'
+echo -n "" > OUTPUT
+for i in ${config_options[*]} ; do
+notmuch config get "${i}"
+done >> OUTPUT
+cat >EXPECTED <. [values ...]"'
+notmuch config set database.path /path/to/maildir
+notmuch config set user.name "User Name"
+notmuch config set user.primary_email primary_email at notmuchmail.org
+notmuch config set user.other_email alt1 at notmuchmail.org alt2 at 
notmuchmail.org
+notmuch config set new.tags tag1 tag2 tag3
+notmuch config set maildir.synchronize_flags false
+echo -n "" > OUTPUT
+for i in ${config_options[*]} ; do
+notmuch config get "${i}"
+done >> OUTPUT
+cat >EXPECTED <."'
+notmuch config set database.path
+notmuch config set user.name
+notmuch config set user.primary_email
+notmuch config set user.other_email
+notmuch config set new.tags
+notmuch config set maildir.synchronize_flags
+echo -n "" > OUTPUT
+for i in ${config_options[*]} ; do
+notmuch config get "${i}"
+done >> OUTPUT
+
+# FIXME: Not the most robust nor portable solution here...
+# Especially `hostname --domain' may have unwanted effects on
+# some platforms, e.g. setting your hostname to "--domain" ;)
+fallback_name="$(grep $(id -un) /etc/passwd | cut -d ":" -f 5 | cut -d "," -f 
1)"
+fallback_email="$(id -un)@$(hostname).$(hostname --domain)"
+
+cat >EXPECTED 

[PATCH] cli: factor out config handling code to get/set lists.

[Pieter Praet]

On Mon, 12 Dec 2011 14:26:21 -0400, David Bremner  wrote:
> On Sun, 11 Dec 2011 20:41:53 +0400, Dmitry Kurochkin  gmail.com> wrote:
> > Hi David.
> > 
> > On Sun, 11 Dec 2011 12:07:51 -0400, David Bremner  
> > wrote:
> > > From: David Bremner 
> > > 
> > > Two new internal routines are created _config_get_list and
> > > _config_set_list; the notmuch_config_get_* functions that deal with
> > > lists are simply wrappers for these functions.
> 
> Updated version pushed. I'm not completely happy with _config_get_list's
> weird API, but I don't have a better idea now.
> 
> d
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

Much cleaner!

However... this would preferrably have been preceded by tests.

Patch follows.


Peace

-- 
Pieter

revised patch for gmime init, with test.

[Pieter Praet]

On Sat, 31 Dec 2011 23:22:46 -0400, David Bremner  wrote:
> It turns out that our existing (trivial) python test is enough to
> catch this bug, but the corpus needs to be augmented.  This
> augmentation is a bit intrusive so I'm thinking of cherry-picking only
> the actual fix to the release branch.
> 

Due to the ~same change being applied in multiple places (and thus
with differing hashes), this has the potential of causing confusion
and/or quite some extra work when debugging using git-bisect(1), so
I'd like to propose that bugfixes for (to-be-)released code are only
applied on the 'maint' branch ('release' in the case of Notmuch),
and then immediately merged back into 'master'.  In fact, this would
preferrably happen after *every* (series of) commit(s) on the 'maint'
branch, to prevent issues like [1].


In this specific case (g_mime_init fix), it would have sufficed to
apply the test suite augmentation patches on 'master' and the bugfix
only on 'maint', merging 'maint' into 'master', and then removing
the "test_subtest_known_broken" line in a followup commit on 'master'.

Thus, maintainers would have fewer merge conflicts to resolve,
developers would at all times benefit from release-specific fixes,
and (pre-)release users would have clear indication of what was fixed
due to the test suite reporting "FIXED" instead of "PASS".


Thanks!

> Unfortunately the test message is 8 bit, so it may be encoded in some
> inconvenient way for patch application. The message is attached to an
> earlier message in the thread if you want to double check.
> 
> I also wondered about putting g_type_init inside the (!initialized)
> test, but decided against it on the grounds of minimality.
> 
> I think we want to in the medium term factor out all of the
> initialization code into one (probably private) function; we can clean
> things up a bit more then.
> 
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch


Peace

-- 
Pieter

[1] id:"87mxa95u3d.fsf at zancas.localnet"

[PATCH 3/3] emacs: colorize buttonized 'id:' links depending on the target message's state

[Pieter Praet]

* emacs/notmuch-show.el (notmuch-show-buttonized-link-present),
* emacs/notmuch-show.el (notmuch-show-buttonized-link-present-and-unread),
* emacs/notmuch-show.el (notmuch-show-buttonized-link-missing):
  new faces for buttonized id: links.

* emacs/notmuch-show.el (notmuch-show-found-target-p): add optional arg
  VERIFY-UNREAD which causes results to be filtered by "tag:unread".

* emacs/notmuch-show.el (notmuch-show-buttonize-links): use different
  face property depending on the result of `notmuch-show-found-target-p',
  causing buttons to present, present-and-unread and missing messages to
  be displayed in a different color.
---
 emacs/notmuch-show.el |   32 +---
 1 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 8f12955..25330c4 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -797,6 +797,27 @@ current buffer, if possible."
 (defvar notmuch-show-buffer-name nil)
 (make-variable-buffer-local 'notmuch-show-buffer-name)

+(defface notmuch-show-buttonized-link-present
+  '((t (:inherit goto-address-mail-face :foreground "blue")))
+  "Face used for buttonized links to messages which are present
+in the mail store."
+  :group 'notmuch-show
+  :group 'notmuch-appearance)
+
+(defface notmuch-show-buttonized-link-present-and-unread
+  '((t (:inherit goto-address-mail-face :foreground "green")))
+  "Face used for buttonized links to messages which are present
+in the mail store, and are tagged `unread'."
+  :group 'notmuch-show
+  :group 'notmuch-appearance)
+
+(defface notmuch-show-buttonized-link-missing
+  '((t (:inherit goto-address-mail-face :foreground "red")))
+  "Face used for buttonized links to messages which are NOT
+present in in the mail store."
+  :group 'notmuch-show
+  :group 'notmuch-appearance)
+
 (defun notmuch-show-buttonize-links (start end)
   "Buttonize URLs and mail addresses between START and END.

@@ -816,7 +837,12 @@ a corresponding notmuch search."
   (notmuch-show-if-found ,message-id))
'follow-link t
'help-echo "Mouse-1, RET: search for this message"
-   'face goto-address-mail-face
+   'face (cond
+  ((notmuch-show-found-target-p message-id t)
+   
'notmuch-show-buttonized-link-present-and-unread)
+  ((notmuch-show-found-target-p message-id)
+   'notmuch-show-buttonized-link-present)
+  (t 'notmuch-show-buttonized-link-missing)))

 ;;;###autoload
 (defun notmuch-show (thread-id  parent-buffer query-context 
buffer-name crypto-switch)
@@ -909,8 +935,8 @@ thread id.  If a prefix is given, crypto processing is 
toggled."
 (notmuch-kill-this-buffer)
 (notmuch-show-worker thread-id parent-buffer query-context buffer-name 
process-crypto)))

-(defun notmuch-show-found-target-p (target)
-  (let ((args `("count" ,target)))
+(defun notmuch-show-found-target-p (target  verify-unread)
+  (let ((args `("count" ,target ,(if verify-unread "and tag:unread" ""
 (> (string-to-number (substring
   (with-output-to-string
 (apply 'call-process notmuch-command nil standard-output nil args))
-- 
1.7.8.1

[PATCH 2/3] emacs: `notmuch-show-buttonize-links' only `notmuch-show's a message if it exists

[Pieter Praet]

* emacs/notmuch-show.el (notmuch-show-found-target-p): new predicate function
  that uses notmuch(1) 'count' to see if a query turns up any results.

* emacs/notmuch-show.el (notmuch-show-if-found): new function that only shows
  a message/thread if present in the database and otherwise returns an error.

* emacs/notmuch-show.el (notmuch-show-buttonize-links): some deduplication,
  and use new function `notmuch-show-if-found' instead of `notmuch-show'
  to prevent showing a blank screen for Message-Id's which aren't present
  in the database.
---
 emacs/notmuch-show.el |   21 ++---
 1 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index c55a1d1..8f12955 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -806,11 +806,14 @@ a corresponding notmuch search."
   (save-excursion
 (goto-char start)
 (while (re-search-forward "id:\\(\"?\\)[^[:space:]\"]+\\1" end t)
+  (let ((message-id (match-string-no-properties 0))
+   (string-start (match-beginning 0))
+   (string-end (match-end 0)))
   ;; remove the overlay created by goto-address-mode
-  (remove-overlays (match-beginning 0) (match-end 0) 'goto-address t)
-  (make-text-button (match-beginning 0) (match-end 0)
+  (remove-overlays string-start string-end 'goto-address t)
+  (make-text-button string-start string-end
'action `(lambda (arg)
-  (notmuch-show ,(match-string-no-properties 
0)))
+  (notmuch-show-if-found ,message-id))
'follow-link t
'help-echo "Mouse-1, RET: search for this message"
'face goto-address-mail-face
@@ -906,6 +909,18 @@ thread id.  If a prefix is given, crypto processing is 
toggled."
 (notmuch-kill-this-buffer)
 (notmuch-show-worker thread-id parent-buffer query-context buffer-name 
process-crypto)))

+(defun notmuch-show-found-target-p (target)
+  (let ((args `("count" ,target)))
+(> (string-to-number (substring
+  (with-output-to-string
+(apply 'call-process notmuch-command nil standard-output nil args))
+  0 -1)) 0)))
+
+(defun notmuch-show-if-found (target  args)
+  (if (notmuch-show-found-target-p target nil)
+  (notmuch-show target args)
+(error (format "Can't find target: %s" target
+
 (defvar notmuch-show-stash-map
   (let ((map (make-sparse-keymap)))
 (define-key map "c" 'notmuch-show-stash-cc)
-- 
1.7.8.1

[PATCH 1/3] emacs: s/buttonise/buttonize/g

[Pieter Praet]

"Worldwide, -ize endings prevail in scientific writing and are commonly
used by many international organizations, such as the ISO and the
WHO. The European Union switched from -ize to -ise some years ago in its
English language publications, and this resulted in the coexistence of
the -ize spelling in older legislative acts and the -ise spelling in
more recent ones." ... and other convincing reasons [1].

Let's follow the good example of academic and standards bodies,
instead of the errors of a non-democratic pseudo-authority [2].

[1] 
http://en.wikipedia.org/wiki/American_and_British_English_spelling_differences#Greek-derived_spellings
[2] http://en.wikipedia.org/wiki/Democratic_deficit_in_the_European_Union
---
 emacs/notmuch-show.el |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 5502efd..c55a1d1 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -797,8 +797,8 @@ current buffer, if possible."
 (defvar notmuch-show-buffer-name nil)
 (make-variable-buffer-local 'notmuch-show-buffer-name)

-(defun notmuch-show-buttonise-links (start end)
-  "Buttonise URLs and mail addresses between START and END.
+(defun notmuch-show-buttonize-links (start end)
+  "Buttonize URLs and mail addresses between START and END.

 This also turns id:\"\"-parts into buttons for
 a corresponding notmuch search."
@@ -874,7 +874,7 @@ buffer."
  (notmuch-show-insert-forest
   (notmuch-query-get-threads basic-args

-  (jit-lock-register #'notmuch-show-buttonise-links)
+  (jit-lock-register #'notmuch-show-buttonize-links)

   ;; Act on visual lines rather than logical lines.
   (visual-line-mode t)
-- 
1.7.8.1

[PATCH v2] emacs: call notmuch-show instead of notmuch-search in buttonised id: links

[Pieter Praet]

On Thu, 22 Dec 2011 20:59:12 -0800, Jameson Graef Rollins  wrote:
> Since message-ids necessarily match just a single message, there's no
> reason to do a search for the id before viewing the actual message;
> the search just becomes an extra screen to click through.  Clicking on
> an id: links now just jumps straight to the message itself.
> ---
> This just fixes the subject of the patch, which had a typo.  Sorry.
> 
>  emacs/notmuch-show.el |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
> index 98db8f2..623d521 100644
> --- a/emacs/notmuch-show.el
> +++ b/emacs/notmuch-show.el
> @@ -803,7 +803,7 @@ a corresponding notmuch search."
>(remove-overlays (match-beginning 0) (match-end 0) 'goto-address t)
>(make-text-button (match-beginning 0) (match-end 0)
>   'action `(lambda (arg)
> -(notmuch-search ,(match-string-no-properties 
> 0)))
> +(notmuch-show ,(match-string-no-properties 
> 0)))
>   'follow-link t
>   'help-echo "Mouse-1, RET: search for this message"
>   'face goto-address-mail-face
> -- 
> 1.7.7.3

Anti-RSI FTW!

However...  If no message with that id: exists, `notmuch-show'
will drop us to a blank screen.

See id:"87lisjzrsc.fsf at kepler.schwinge.homeip.net" for some mock
'id:' links which demonstrate this nicely.

Patches follow.


Peace

-- 
Pieter

RFC: use the XDG Base Directory Specification for configuration data

[Pieter Praet]

On Wed, 21 Dec 2011 11:35:37 -0800, Jameson Graef Rollins  wrote:
> On Wed, 21 Dec 2011 07:44:16 -0400, David Bremner  
> wrote:
> [SNIP]
> 
> > On my machine all of the programs (except nottoomuch ;) ) that use
> > ~/.config are gui based, and a bunch of them store binary blobs (or not
> > plain text anyway) there. It might be irrational, but I don't really
> > want notmuch to be associated with that crowd ;).
> 
> It's not all gui applications.  I see multiple non-gui apps storing
> their config in there.  I would personally love it if everything
> respected that standard.  It would clear up my home directory
> significantly.
> 

Full ACK!

> jamie.


Peace

-- 
Pieter

Code Style Bikeshed 1/n: Break before Brace or Brace before Break?

[Pieter Praet]

On Sun, 18 Dec 2011 20:18:03 +0400, Dmitry Kurochkin  wrote:
> On Sun, 18 Dec 2011 18:12:51 +0200, Tomi Ollila  wrote:
> > On Sun, 18 Dec 2011 19:50:52 +0400, Dmitry Kurochkin  > gmail.com> wrote:
> > > +1 for the former.
> > 
> > +1
> > 
> > > How about indenting with spaces+tabs vs indenting with spaces only? :)
> > 
> > -1 --   tab-width is 8, anything else is heretic. Everyone enable 
> > git pre-commit hook :)
> > 
> 
> Sorry, -1 for what? :)
> 
> FWIW tabs make patch review a pain in our favourite interface to our
> favourite mail system because of message indenting.
> 

~+1...

Neither the tabs nor the spaces impede patch review from within Notmuch.

The real cause of this confusing indentation is that we're using *both*,
which -from my point of view- makes absolutely no sense.

Personally, I'd like to see

  ;; -*- tab-width: 2; indent-tabs-mode: nil; -*-

... but frankly, I don't care whether it's tabs or spaces, or whether
it's mod-2, mod-4 or mod-8... as long as it's *tabs XOR spaces*.


And brace-before-break, of course... :)


So, when's this bikeshed due to be delivered ?
Also, if I order *now*, do I get a complementary cheese grater ?

> Regards,
>   Dmitry
> 
> > > Regards,
> > >   Dmitry
> > 
> > Tomi


Peace

-- 
Pieter

[PATCH] notmuch/emacs: Observe the charset of encoded parts, where known.

[Dmitry Kurochkin]

Hi David.

On Thu, 12 Jan 2012 12:00:14 +, David Edmondson  wrote:
> On Wed, 11 Jan 2012 22:34:45 +0400, Dmitry Kurochkin  gmail.com> wrote:
> > -1
> 
> Which puts me back to 0 :-(
> 
> > One particular issue with your patch is that it adds (incorrect) charset
> > parameter to plain/text parts which are converted to UTF-8 in JSON
> > output.
> 
> Patches that break things should obviously not be accepted...
> 
> > I already tried to solve the above problem using a more general approach
> > (output all content-type parameters, not just charset) [1].  There was a
> > lengthy discussion on IRC about it and it was rejected.  The consensus
> > was that we need to make some more substantial changes to JSON and raw
> > output formats to properly fix the issue (and the issue is more general
> > than what this patch fixes, other content-type parameters are useful for
> > renderers as well and should be included in the output).
> 
> ...but a useful point fix should not be blocked by theoretical future
> work.
> 

I think there is a record of useful features and fixes that were not
accepted to notmuch because of some implementation issues.  And
interested people were using them in private repos for years.  (I do not
say that it is always the right thing to do, or that it is the right
thing in this particular case.)

> > I am planning to work on a proper fix for this issue, but decided to
> > postpone it until Austin's rewrite of notmuch show is complete.
> 
> If the UTF8 text/plain part issue can be resolved, would you be happier
> to accept this as an interim fix whilst we wait for the more complete
> solution?
> 

I would like to see the following changes:

* Properly handle charset with parameters in Emacs UI.  Currently it is
  broken by your patch in one place at least:
  `notmuch-show-handlers-for' would produce incorrect results for
  content-type string with parameters.  In my patch [1] I did parse the
  charset at top level and then changed all usages of it accordingly.
  Making `notmuch-show-handlers-for' smarter about parameters may be
  sufficient, but I would like to see some more details on why adding
  parameters to content-type string does not break Emacs UI code in
  other places.

* Add charset parameter for text/html parts only.

* Use `mail-header-parse-content-type' to parse content-type instead of
  contructing the list for `mm-make-handle' manually.

* Add a proper XXX comment to notmuch-show code.

I cannot say I would be happy about this patch after these changes.  It
would be a temporary hack anyway.  But I would withdraw my -1 and let
others decide.  I would like to see Jameson and Austin input on this
one.

Regards,
  Dmitry

[1] id:"1321659905-24367-1-git-send-email-dmitry.kurochkin at gmail.com"

> Nothing in the patch (so far) should make your proposed changes any
> harder, so I'm not sure what the problem would be.

[PATCH] Set fill column to 70 in .dir-locals.el.

[Austin Clements]

This controls where comments and other text wraps.  70 is the default
value, so this simply returns it to the default for people who have
overridden it.  Most notmuch code already adheres to this.
---
 .dir-locals.el |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/.dir-locals.el b/.dir-locals.el
index aea630b..044c214 100644
--- a/.dir-locals.el
+++ b/.dir-locals.el
@@ -20,4 +20,6 @@
   (tab-width . 8)
   (sh-basic-offset . 4)
   (sh-indentation . 4))
+ (nil
+  (fill-column . 70))
  )
-- 
1.7.7.3

[PATCH] test: don't bail out of `run_emacs' too early when missing prereqs

[Pieter Praet]

When running the Emacs tests in verbose mode, only the first missing
prereq is reported because the `run_emacs' function is short-circuited
early:

  #+begin_example
emacs: Testing emacs interface
 missing prerequisites: [0]  emacs(1)
 skipping test: [0]  Basic notmuch-hello view in emacs
 SKIP   [0]  Basic notmuch-hello view in emacs
  #+end_example

This can lead to situations reminiscent of "dependency hell", so instead
of returning based on each individual `test_require_external_prereq's exit
status, we now do so by checking $test_subtest_missing_external_prereqs_:

  #+begin_example
emacs: Testing emacs interface
 missing prerequisites: [0]  dtach(1) emacs(1) emacsclient(1)
 skipping test: [0]  Basic notmuch-hello view in emacs
 SKIP   [0]  Basic notmuch-hello view in emacs
  #+end_example

Also add missing prereq for dtach(1).

---
 test/test-lib.sh |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/test/test-lib.sh b/test/test-lib.sh
index 82767c0..6ec3882 100644
--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -907,8 +907,10 @@ EOF

 test_emacs () {
# test dependencies beforehand to avoid the waiting loop below
-   test_require_external_prereq emacs || return
-   test_require_external_prereq emacsclient || return
+   test_require_external_prereq dtach
+   test_require_external_prereq emacs
+   test_require_external_prereq emacsclient
+   test -z "$test_subtest_missing_external_prereqs_" || return

if [ -z "$EMACS_SERVER" ]; then
server_name="notmuch-test-suite-$$"
-- 
1.7.8.1

[PATCH v3 00/7] test: (hopefully) better test prerequisites

[Pieter Praet]

On Sun, 27 Nov 2011 22:36:12 +0400, Dmitry Kurochkin  wrote:
> Changes:
> 
> v3 since v2:
> 
> * rebased the remaining patches on current master
> 
> v2 since v1:
> 
> * Add test_require_external_prereq function to explicitly check for
>   external dependencies, use it in test_emacs.
> 
> * Indenting fixes.
> 
> * Use $binary instead of $1 in test_declare_external_prereq.
> 
> Regards,
>   Dmitry
> 
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

Fantastic work Dmitry!  My inept dabblings are thoroughly humbled
by the elegance of this approach!

All that's left to go from three to four nines, is ensuring correct
$test_{count,success,fixed,broken,failure} reports (which can most
definitively be categorized as "non-trivial")...

  Eg. with and without emacs(1), emacsclient(1), dtach(1), gpg(1) :

#+begin_example
  Notmuch test suite complete.
  All 347 tests behaved as expected (2 expected failures).
#+end_example

#+begin_example
  Notmuch test suite complete.
  266/312 tests passed.
  1 broken test failed as expected.
  5 tests failed.
  40 tests skipped.
#+end_example

... as well as a minor issue re test_emacs(), which will be
addressed in a followup patch.


Peace

-- 
Pieter

[PATCH v2] emacs: logically group def{custom,face}s

[Pieter Praet]

To allow for expansion whilst keeping everything tidy and organized,
move all defcustom/defface variables to the following subgroups,
defined in notmuch-lib.el:

- Hello
- Search
- Show
- Send
- Crypto
- Hooks
- Appearance
- External Commands

As an added benefit, defcustom keyword args are now consistently
in order of appearance @ defcustom's docstring (OCD much?).
---
 emacs/notmuch-address.el |3 +-
 emacs/notmuch-crypto.el  |   22 +---
 emacs/notmuch-hello.el   |   34 ++--
 emacs/notmuch-lib.el |   44 -
 emacs/notmuch-maildir-fcc.el |6 ++--
 emacs/notmuch-message.el |2 +-
 emacs/notmuch-mua.el |   21 ++-
 emacs/notmuch-show.el|   33 ---
 emacs/notmuch.el |   35 +
 9 files changed, 131 insertions(+), 69 deletions(-)

diff --git a/emacs/notmuch-address.el b/emacs/notmuch-address.el
index 8eba7a0..2e8b840 100644
--- a/emacs/notmuch-address.el
+++ b/emacs/notmuch-address.el
@@ -28,7 +28,8 @@
 single argument and output a list of possible matches, one per
 line."
   :type 'string
-  :group 'notmuch)
+  :group 'notmuch-send
+  :group 'notmuch-external)

 (defvar notmuch-address-message-alist-member
   
'("^\\(Resent-\\)?\\(To\\|B?Cc\\|Reply-To\\|From\\|Mail-Followup-To\\|Mail-Copies-To\\):"
diff --git a/emacs/notmuch-crypto.el b/emacs/notmuch-crypto.el
index ac30098..232c1a0 100644
--- a/emacs/notmuch-crypto.el
+++ b/emacs/notmuch-crypto.el
@@ -34,38 +34,44 @@ The effect of setting this variable can be seen temporarily 
by
 providing a prefix when viewing a signed or encrypted message, or
 by providing a prefix when reloading the message in notmuch-show
 mode."
-  :group 'notmuch
-  :type 'boolean)
+  :type 'boolean
+  :group 'notmuch-crypto)

 (defface notmuch-crypto-part-header
   '((t (:foreground "blue")))
   "Face used for crypto parts headers."
-  :group 'notmuch)
+  :group 'notmuch-crypto
+  :group 'notmuch-appearance)

 (defface notmuch-crypto-signature-good
   '((t (:background "green" :foreground "black")))
   "Face used for good signatures."
-  :group 'notmuch)
+  :group 'notmuch-crypto
+  :group 'notmuch-appearance)

 (defface notmuch-crypto-signature-good-key
   '((t (:background "orange" :foreground "black")))
   "Face used for good signatures."
-  :group 'notmuch)
+  :group 'notmuch-crypto
+  :group 'notmuch-appearance)

 (defface notmuch-crypto-signature-bad
   '((t (:background "red" :foreground "black")))
   "Face used for bad signatures."
-  :group 'notmuch)
+  :group 'notmuch-crypto
+  :group 'notmuch-appearance)

 (defface notmuch-crypto-signature-unknown
   '((t (:background "red" :foreground "black")))
   "Face used for signatures of unknown status."
-  :group 'notmuch)
+  :group 'notmuch-crypto
+  :group 'notmuch-appearance)

 (defface notmuch-crypto-decryption
   '((t (:background "purple" :foreground "black")))
   "Face used for encryption/decryption status messages."
-  :group 'notmuch)
+  :group 'notmuch-crypto
+  :group 'notmuch-appearance)

 (define-button-type 'notmuch-crypto-status-button-type
   'action (lambda (button) (message (button-get button 'help-echo)))
diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index 333d4c1..fad9027 100644
--- a/emacs/notmuch-hello.el
+++ b/emacs/notmuch-hello.el
@@ -35,12 +35,12 @@
 (defcustom notmuch-recent-searches-max 10
   "The number of recent searches to store and display."
   :type 'integer
-  :group 'notmuch)
+  :group 'notmuch-hello)

 (defcustom notmuch-show-empty-saved-searches nil
   "Should saved searches with no messages be listed?"
   :type 'boolean
-  :group 'notmuch)
+  :group 'notmuch-hello)

 (defun notmuch-sort-saved-searches (alist)
   "Generate an alphabetically sorted saved searches alist."
@@ -60,7 +60,7 @@ alist to be used."
 (const :tag "Sort alphabetically" notmuch-sort-saved-searches)
 (function :tag "Custom sort function"
   :value notmuch-sort-saved-searches))
-  :group 'notmuch)
+  :group 'notmuch-hello)

 (defvar notmuch-hello-indent 4
   "How much to indent non-headers.")
@@ -68,12 +68,13 @@ alist to be used."
 (defcustom notmuch-show-logo t
   "Should the notmuch logo be shown?"
   :type 'boolean
-  :group 'notmuch)
+  :group 'notmuch-hello
+  :group 'notmuch-appearance)

 (defcustom notmuch-show-all-tags-list nil
   "Should all tags be shown in the notmuch-hello view?"
   :type 'boolean
-  :group 'notmuch)
+  :group 'notmuch-hello)

 (defcustom notmuch-hello-tag-list-make-query nil
   "Function or string to generate queries for the all tags list.
@@ -89,12 +90,12 @@ should return a filter for that tag, or nil to hide the 
tag."
 (string :tag "Custom filter"
 :value "tag:unread")
 (function :tag "Custom filter function"))
-  :group 'notmuch)
+  :group 'notmuch-hello)

[PATCH v2] Output unmodified Content-Type header value for JSON format.

[Pieter Praet]

On Sun, 20 Nov 2011 22:35:42 +0400, Dmitry Kurochkin  wrote:
> On Sat, 19 Nov 2011 08:59:29 -0400, David Bremner  
> wrote:
> > On Sat, 19 Nov 2011 08:18:41 +0400, Dmitry Kurochkin  > gmail.com> wrote:
> > > Before the change, notmuch used g_mime_content_type_to_string(3)
> > > function to output Content-Type header value.  Turns out it outputs
> > > only "type/subtype" part and ignores all parameters.  Also, if there
> > > is no Content-Type header, default "text/plain" value is used.
> > 
> > Hi Dmitry;
> > 
> > I haven't analyzed the substance of your patch yet, but I did have a
> > couple thoughts while reading your mail.
> > 
> > - It seems that every time we change the json format, we have a round of
> >   suffering because people are unable to detect a mismatch between their
> >   emacs code and the cli. Not that this is your problem necessarily, but
> >   it would be nice if someone (TM), would come up with some version info
> >   for the json output, and a patch to check it on the emacs side.
> > 
> 
> IMO this is a good idea.
> 
> > - The previous point is a bit of a counterargument to this, but in
> >   general, I think I prefer patches that modify the core seperate from
> >   those that do emacs (or python, or ...) stuff.
> > 
> 
> I couls separate it.  I made is a single patch to avoid having a
> revision with broken emacs UI (and tests).
> 

I'd like to propose to always apply patch series on a *topic* branch
which would then be merged back into 'master', thus avoiding this issue
altogether whilst making it more obvious which patches belong together
(eg. for easier cross-referencing with the ML).

> Regards,
>   Dmitry
> 
> > - I understand you want to make your patches reviewable without applying
> >   by including lots of context, but at a certain point it has actually
> >   the opposite effect for me. I just don't read 900+ line emails ;). Of
> >   course, I can still apply the patch and look at it, so it's really up
> >   to you.
> > 
> > d
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch


Peace

-- 
Pieter

[PATCH] Output unmodified Content-Type header value for JSON format.

[Pieter Praet]

On Tue, 22 Nov 2011 22:40:21 -0500, Austin Clements  wrote:
> Quoth Jameson Graef Rollins on Nov 20 at 12:10 pm:
> > The open question seems to be how we handle the content encoding
> > parameters.  My argument is that those should either be used by notmuch
> > to properly encode the content for the consumer.  If that's not
> > possible, then just those parameters needed by the consumer to decode
> > the content should be output.
> 
> If notmuch is going to include part content in the JSON output (which
> perhaps it shouldn't, as per recent IRC discussions), then it must
> handle content encodings because JSON must be Unicode and therefore
> the content strings in the JSON must be Unicode.

Having missed the IRC discussions: what is the rationale for not
including (specific types of?) part content in the JSON output ?
Eg. how about inline attached text/x-patch ?

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


Peace

-- 
Pieter

[PATCH 0/6] Rebase of Pieter's "set test prereqs"

[Pieter Praet]

On Thu, 17 Nov 2011 11:14:11 +0100, Thomas Jost  
wrote:
> On Wed, 16 Nov 2011 21:50:17 +0100, Pieter Praet  wrote:
> > On Wed, 16 Nov 2011 15:33:49 +0100, Thomas Jost  
> > wrote:
> > > Hello list,
> > > 
> > > This is another rebased version of Pieter's series to add GPG and Emacs 
> > > as test
> > > prereqs, plus some additions on my own. (Rebased and posted as requested 
> > > by
> > > Pieter [1].)
> > > 
> > 
> > Thanks Thomas!
> > 
> > Although... you may have misread (or maybe I mistyped :), but what I
> > actually intended [1] was for you to rebase *only* your fixes on top of
> > my rebased series (e.g. see "tjost-fixes.patch" in att), so you could
> > receive proper credit for cleaning up my mess.
> 
> Oh, ok, I must have misread that :) 
> 
> Right now your patches don't apply cleanly on master (conflict in patch
> 3 due to commit 5964a7), and I think that Dmitry's patches [1] may be a
> better way to handle prereqs. So I probably won't send those patches
> until we decide which approach is the way to go.
> 
> [1] id:"1321494986-18998-1-git-send-email-dmitry.kurochkin at gmail.com"
> 

Yup, Dmitry's solution is much more elegant!

> > Also, while my apprehension [2,3] re the inclusion of the SCREEN/DTACH
> > prereq in patches #4,5,6 didn't have much merit (it's an all-or-nothing
> > affair anyways), the issue [3] in patch #5 @ "Reply within emacs" still
> > stands: `sed' will run unconditionally, and treat "EMACS" as an input
> > file.  (see "sed-prereq-fix.patch" in att).
> 
> Nice catch with this sed issue. Looks like I need to be more careful
> when replacing "OUTPUT" with "EMACS OUTPUT"...
> 
> Thanks,
> 
> -- 
> Thomas/Schnouki


Peace

-- 
Pieter

[PATCH 2/2] NEWS: fix some old typos and trailing whitespace

[Pieter Praet]

On Thu, 17 Nov 2011 08:21:59 +0200, Jani Nikula  wrote:
> On Nov 16, 2011 11:39 PM, "Pieter Praet"  wrote:
> >
> > On Wed, 16 Nov 2011 22:54:35 +0200, Tomi Ollila 
> wrote:
> > > On Wed, 16 Nov 2011 21:37:50 +0100, Pieter Praet 
> wrote:
> > > > No further explanation needed.
> > > > ---
> > > >  NEWS |   14 +++---
> > > >  1 files changed, 7 insertions(+), 7 deletions(-)
> > >
> > > The 'No further explanation needed.' should be *BELOW* the waistline
> (---) ;);
> > > now it goes to the commit message which is probably not what anybody
> wants.
> > >
> >
> > That was intended :)
> >
> > Empty commit messages are frowned upon (even if the commit subject is
> > sufficiently descriptive), so "rather a pointless one than none?" :)
> 
> Generally I think the message should be self-contained and understandable
> without the subject line, so IMHO a full meaningful sentence is better than
> one/none, even if it's repetition.
> 
> BR,
> Jani.

That would indeed have been the most sensible thing to do.

Could someone (who -unlike me- has already submitted his/her public SSH
key for commit access) add something along those lines to the Patch
Formatting guidelines [1] ?  Perhaps just quote Carl's statement [2] ?


Peace

-- 
Pieter

[1] http://notmuchmail.org/patchformatting/
[2] id:"87ocmwok2w.fsf at yoom.home.cworth.org"

[PATCH] emacs: breakout notmuch-show-advance functionality from notmuch-show-advance-and-archive

[Pieter Praet]

On Wed, 16 Nov 2011 23:47:53 +0100, Pieter Praet  wrote:
> On Sun, 13 Nov 2011 13:16:48 -0800, Jameson Graef Rollins  finestructure.net> wrote:
> > This patch breaks out much of the functionality of
> > notmuch-show-advance-and-archive into a new function:
> > notmuch-show-advance.  This new function does all the advancing
> > through a show buffer that notmuch-show-advance-and-archive did,
> > without all the invasive thread archiving.  The return value of
> > notmuch-show-advance is nil if the bottom of the thread is not
> > reached, and t if it is.
> > 
> > notmuch-show-advance-and-archive is modified to just call
> > notmuch-show-advance, and then call notmuch-show-archive-thread if the
> > return value is true.  In this way the previous functionality of
> > notmuch-show-advance-and-archive is preserved.
> > 
> > This provides a way for people to rebind the space bar to a more sane
> > function if they don't like the default behavior.
> > ---
> >  emacs/notmuch-show.el |   38 +++---
> >  1 files changed, 23 insertions(+), 15 deletions(-)
> > 
> > diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
> > index d5c95d8..a7f3263 100644
> > --- a/emacs/notmuch-show.el
> > +++ b/emacs/notmuch-show.el
> > @@ -1135,26 +1135,18 @@ All currently available key bindings:
> >  
> >  ;; Commands typically bound to keys.
> >  
> > -(defun notmuch-show-advance-and-archive ()
> > -  "Advance through thread and archive.
> > -
> > -This command is intended to be one of the simplest ways to
> > -process a thread of email. It does the following:
> > +(defun notmuch-show-advance ()
> > +  "Advance through thread.
> >  
> >  If the current message in the thread is not yet fully visible,
> >  scroll by a near screenful to read more of the message.
> >  
> >  Otherwise, (the end of the current message is already within the
> > -current window), advance to the next open message.
> > -
> > -Finally, if there is no further message to advance to, and this
> > -last message is already read, then archive the entire current
> > -thread, (remove the \"inbox\" tag from each message). Also kill
> > -this buffer, and display the next thread from the search from
> > -which this thread was originally shown."
> > +current window), advance to the next open message."
> >(interactive)
> >(let* ((end-of-this-message (notmuch-show-message-bottom))
> > -(visible-end-of-this-message (1- end-of-this-message)))
> > +(visible-end-of-this-message (1- end-of-this-message))
> > +(ret nil))
> >  (while (invisible-p visible-end-of-this-message)
> >(setq visible-end-of-this-message
> > (previous-single-char-property-change visible-end-of-this-message
> > @@ -1173,8 +1165,24 @@ which this thread was originally shown."
> >(notmuch-show-next-open-message))
> >  
> >   (t
> > -  ;; This is the last message - archive the thread.
> > -  (notmuch-show-archive-thread)
> > +  ;; This is the last message - change the return value
> > +  (setq ret t)))
> > +ret))
> > +
> > +(defun notmuch-show-advance-and-archive ()
> > +  "Advance through thread and archive.
> > +
> > +This command is intended to be one of the simplest ways to
> > +process a thread of email. It works exactly like
> > +notmuch-show-advance, in that it scrolls through messages in a
> > +show buffer, except that when it gets to the end of the buffer it
> > +archives the entire current thread, (remove the \"inbox\" tag
> > +from each message), kills the buffer, and displays the next
> > +thread from the search from which this thread was originally
> > +shown."
> > +  (interactive)
> > +  (if (notmuch-show-advance)
> > +  (notmuch-show-archive-thread)))
> >  
> >  (defun notmuch-show-rewind ()
> >"Backup through the thread, (reverse scrolling compared to 
> > \\[notmuch-show-advance-and-archive]).
> > -- 
> > 1.7.7.1
> > 
> > ___
> > notmuch mailing list
> > notmuch at notmuchmail.org
> > http://notmuchmail.org/mailman/listinfo/notmuch
> 
> 
> Nice one!
> 
> Signed-off-by: Pieter Praet   ;)
> 
> 
> This has also exposed a pre-existing bug: When the last visible message
> is longer than a screenful and contains a *hidden* signature, you'll
> never get to see the end of it.
> 
> The culprit is presumably seeking shelter from the flyswatter @
> `notmuch-show-message-extent' or one of its relatives: Cc'ing our
> resident invisibility guru.
> 
> 
> Peace
> 
> -- 
> Pieter


FYI, this bug has been fixed by Aaron Ecay [1], commit 8392a7cc, which
will be included in v0.12.  Not accompanied by a test, though, so keep
an eye out for regressions.

Maybe the following might be of use to someone:

  #+begin_src sh
msg_lines=25
sh -c "stty rows 24 cols 80; \
emacs -Q -nw --eval \
'(progn
(dotimes (i ${msg_lines}) (insert \"\n\"))
(goto-char (point-min))
(scroll-up nil)
(princ 

0.11 is frozen, please update NEWS

[Pieter Praet]

On Sun, 25 Dec 2011 15:55:43 -0400, David Bremner  wrote:
> 
> Well, it's -19C outside, so guess that is appropriate.
> 
> I have merged master to release in preparation for release. There should
> only be additions to NEWS or fixes for serious bugs for branch release
> until 0.11 is out the door.
> 
> Speaking of NEWS, please have a look at the commits listed under your
> name, and if they impact user experience, then consider a patch for
> NEWS. As an experiment, I set up write access to branch "news" of
> 
>   git at pivot.cs.unb.ca:pub/notmuch
> 
> I used the ssh keys people sent me for nmbug; feel free to send me more
> (public) keys. The idea is it might be less painful to edit NEWS on that
> branch.  Of course, all the old methods are fine too.
> 
> 
> Aaron Ecay (3):
>   Ignore dynamic libraries on OS X.
>   Add an argument to notmuch-mua-mail
>   emacs: fix off-by-one bug in notmuch-show-archive
> 
> Ali Polatel (2):
>   notmuch-deliver: Import from maildrop-2.5.5
>   notmuch-deliver: GPL-3+
> 
> Austin Clements (2):
>   emacs: Don't record undo information for search or show buffers.
>   emacs: Avoid unnecessary markers.
> 
> David Edmondson (1):
>   emacs: Add `notmuch-jump-to-recent-buffer'.
> 
> Dmitry Kurochkin (31):
>   emacs: do not call notmuch show for non-inlinable parts
>   emacs: put the last search on top of recent searches in notmuch-hello
> 
> Gregor Zattler (1):
>   emacs: make message indentation width customisable
> 
> 
> Ivy Foster (1):
>   emacs: Add notmuch-hello-mode-hook
> 
> Jameson Graef Rollins (2):
>   emacs: breakout notmuch-show-advance functionality from 
> notmuch-show-advance-and-archive
>   emacs: call notmuch-show instead of notmuch-search in buttonised id: 
> links
> 
> Jani Nikula (8):
>   emacs: Add new customization option to sort saved searches
>   emacs: Make saving new saved searches append, not prepend
>   cli: introduce the concept of user defined hooks
>   cli: add support for pre and post notmuch new hooks
>   emacs: support "notmuch new" as a notmuch-poll-script
>   emacs: Fix notmuch-hello-tag-list-make-query defcustom
>   emacs: Fix notmuch-mua-user-agent defcustom
> 
> Justus Winter (2):
>   python: add classes to wrap all notmuch_*_t types
>   python: annotate all calls into libnotmuch with types
> 
> Louis Rilling (2):
>   lib: Kill last usage of C++ type bool
>   tags_to_maildir_flags: Cleanup double assignement
> 
> Patrick Totzke (3):
>   use __unicode__ for string representation
>   errors='ignore' when decode to unicode
>   fix format string in Message.__unicode__
> 
> Sebastian Spaeth (2):
>   python: Return a STATUS value in tags_to_flags and flags_to_tags
>   python: Remove stray debug comment
> 
> Thomas Jost (6):
>   python: use wrapped notmuch_*_t types instead of raw pointers
>   emacs: Add a face for crypto parts headers
>   Fix build with binutils-2.22
>   emacs: add notmuch-hello-refresh-hook
>   emacs: rename notmuch-decimal-separator to 
> notmuch-hello-thousands-separator
>   emacs: Change the default thousands separator to a space
> 
> Thomas Schwinge (1):
>   dump: Don't sort the output by message id.
> 
> Tomi Ollila (2):
>   Release memory allocated by internet_address_list_parse_string()
>   notmuch: unref charset_filter to fix one memory leak
> 
> pazz (2):
>   test: date_relative in notmuch search json output
>   json: date_relative for threads
> 
> 

Wow!  I'm absolutely blown away by the huge amount of *awesome* work
that has been going on here while I muted some lists for a little while!
(which in retrospect may not have been such a good idea, catching up is
proving to be a task of Herculean proportions...)

Major respect and thanks to *all* past and present contributors,
and extra props to David Bremner, whose dedication is truly exemplary,
and Carl Worth -of course- for starting it all !

Due to personal objections regarding the origin, intentions, execution
and repercussions of the concepts "Christmas", "New Year", et al.,
I won't be wishing any merry nor happy ${insert_preferred_holiday}s,
but instead wish you all a happy and prolific *Every*day, since each
and every one of them is worth celebrating !


Peace

-- 
Pieter

[PATCH v4 2/5] cli: add support for replying just to the sender in "notmuch reply"

[Austin Clements]

LGTM.  Again, one minor nit below, but not enough to hold up this
patch.

Quoth Jani Nikula on Jan 12 at 11:40 pm:
> Add new option --reply-to=(all|sender) to "notmuch reply" to select whether
> to reply to all (sender and all recipients), or just sender. Reply to all
> remains the default.
> 
> Credits to Mark Walters  for his similar earlier
> work where I picked up the basic idea of handling reply-to-sender in
> add_recipients_from_message(). All bugs are mine, though.
> 
> Signed-off-by: Jani Nikula 
> 
> ---
> 
> Settled on --reply-to=(all|sender) per Carl's earlier suggestion
> (id:87pqn5cg4g.fsf at yoom.home.cworth.org) and David's approval on IRC.
> ---
>  man/man1/notmuch-reply.1 |   28 
>  notmuch-reply.c  |   52 +
>  2 files changed, 65 insertions(+), 15 deletions(-)
> 
> diff --git a/man/man1/notmuch-reply.1 b/man/man1/notmuch-reply.1
> index db464d8..5160ece 100644
> --- a/man/man1/notmuch-reply.1
> +++ b/man/man1/notmuch-reply.1
> @@ -14,11 +14,13 @@ Constructs a reply template for a set of messages.
>  To make replying to email easier,
>  .B notmuch reply
>  takes an existing set of messages and constructs a suitable mail
> -template. The Reply-to header (if any, otherwise From:) is used for
> -the To: address. Vales from the To: and Cc: headers are copied, but
> -not including any of the current user's email addresses (as configured
> -in primary_mail or other_email in the .notmuch\-config file) in the
> -recipient list
> +template. The Reply-to: header (if any, otherwise From:) is used for
> +the To: address. Unless
> +.BR \-\-reply-to=sender
> +is specified, values from the To: and Cc: headers are copied, but not
> +including any of the current user's email addresses (as configured in
> +primary_mail or other_email in the .notmuch\-config file) in the
> +recipient list.
>  
>  It also builds a suitable new subject, including Re: at the front (if
>  not already present), and adding the message IDs of the messages being
> @@ -45,6 +47,22 @@ Includes subject and quoted message body.
>  Only produces In\-Reply\-To, References, To, Cc, and Bcc headers.
>  .RE
>  .RE
> +.RS
> +.TP 4
> +.BR \-\-reply\-to= ( all | sender )
> +.RS
> +.TP 4
> +.BR all " (default)"
> +Replies to all addresses.
> +.TP 4
> +.BR sender
> +Replies only to the sender. If replying to user's own message
> +(Reply-to: or From: header is one of the user's configured email
> +addresses), try To:, Cc:, and Bcc: headers in this order, and copy
> +values from the first that contains something other than only the
> +user's addresses.
> +.RE
> +.RE
>  
>  See \fBnotmuch-search-terms\fR(7)
>  for details of the supported syntax for .
> diff --git a/notmuch-reply.c b/notmuch-reply.c
> index 4fae66f..b4c81de 100644
> --- a/notmuch-reply.c
> +++ b/notmuch-reply.c
> @@ -289,7 +289,14 @@ reply_to_header_is_redundant (notmuch_message_t *message)
>  return 0;
>  }
>  
> -/* Augments the recipients of reply from the headers of message.
> +/* Augment the recipients of 'reply' from the "Reply-to:", "From:", "To:",
> + * "Cc:", and "Bcc:" headers of 'message'.
> + *
> + * If 'reply_all' is true, use sender and all recipients, otherwise scan the
> + * headers for the first that contains something other than the user's 
> addresses
> + * and add the recipients from this header (typically this would be
> + * reply-to-sender, but also handles reply to user's own message in a 
> sensible
> + * way).

Same comment about 80 column wrapping.

>   *
>   * If any of the user's addresses were found in these headers, the first
>   * of these returned, otherwise NULL is returned.
> @@ -297,7 +304,8 @@ reply_to_header_is_redundant (notmuch_message_t *message)
>  static const char *
>  add_recipients_from_message (GMimeMessage *reply,
>notmuch_config_t *config,
> -  notmuch_message_t *message)
> +  notmuch_message_t *message,
> +  notmuch_bool_t reply_all)
>  {
>  struct {
>   const char *header;
> @@ -311,6 +319,7 @@ add_recipients_from_message (GMimeMessage *reply,
>  };
>  const char *from_addr = NULL;
>  unsigned int i;
> +unsigned int n = 0;
>  
>  /* Some mailing lists munge the Reply-To header despite it being A Bad
>   * Thing, see http://www.unicom.com/pw/reply-to-harmful.html
> @@ -337,8 +346,23 @@ add_recipients_from_message (GMimeMessage *reply,
>   recipients = notmuch_message_get_header (message,
>reply_to_map[i].fallback);
>  
> - scan_address_string (recipients, config, reply,
> -  reply_to_map[i].recipient_type, _addr);
> + n += scan_address_string (recipients, config, reply,
> +   reply_to_map[i].recipient_type, _addr);
> +
> + if (!reply_all && n) {
> + /* Stop adding new recipients in 

[PATCH v4 1/5] cli: slightly refactor "notmuch reply" address scanning functions

[Austin Clements]

LGTM.  One thing you could fix below (and a few comments), but not
enough alone to warrant a new version.

Quoth Jani Nikula on Jan 12 at 11:40 pm:
> Slightly refactor "notmuch reply" recipient and user from address scanning
> functions in preparation for reply-to-sender feature.
> 
> Add support for not adding messages at all (just scan for user from
> address), and returning the number of messages added.
> 
> No externally visible functional changes.
> 
> Signed-off-by: Jani Nikula 
> ---
>  notmuch-reply.c |   74 --
>  1 files changed, 38 insertions(+), 36 deletions(-)
> 
> diff --git a/notmuch-reply.c b/notmuch-reply.c
> index 000f6da..4fae66f 100644
> --- a/notmuch-reply.c
> +++ b/notmuch-reply.c
> @@ -168,22 +168,28 @@ address_is_users (const char *address, notmuch_config_t 
> *config)
>  return 0;
>  }
>  
> -/* For each address in 'list' that is not configured as one of the
> - * user's addresses in 'config', add that address to 'message' as an
> - * address of 'type'.
> +/* Scan addresses in 'list'.
>   *
> - * The first address encountered that *is* the user's address will be
> - * returned, (otherwise NULL is returned).
> + * If 'message' is non-NULL, then for each address in 'list' that is not
> + * configured as one of the user's addresses in 'config', add that address to
> + * 'message' as an address of 'type'.
> + *
> + * If 'user_from' is non-NULL and *user_from is NULL, the first address
> + * encountered in 'list' that *is* the user's address will be set to 
> *user_from.
> + *
> + * Return the number of addresses added to 'message'. (If 'message' is NULL, 
> the
> + * function returns 0 by definition.)

Ah, I like the return value.  Better than adding an umpteenth argument
like I was suggesting.

>   */
> -static const char *
> -add_recipients_for_address_list (GMimeMessage *message,
> -  notmuch_config_t *config,
> -  GMimeRecipientType type,
> -  InternetAddressList *list)
> +static unsigned int
> +scan_address_list (InternetAddressList *list,
> +notmuch_config_t *config,
> +GMimeMessage *message,
> +GMimeRecipientType type,
> +const char **user_from)
>  {
>  InternetAddress *address;
>  int i;
> -const char *ret = NULL;
> +unsigned int n = 0;
>  
>  for (i = 0; i < internet_address_list_length (list); i++) {
>   address = internet_address_list_get_address (list, i);
> @@ -196,8 +202,7 @@ add_recipients_for_address_list (GMimeMessage *message,
>   if (group_list == NULL)
>   continue;
>  
> - add_recipients_for_address_list (message, config,
> -  type, group_list);
> + n += scan_address_list (group_list, config, message, type, NULL);

Should the NULL above be user_from?  You're being compatible with the
original code, which is the right thing to do in this patch, but the
new-found explicitness made me wonder if this is actually a bug.

>   } else {
>   InternetAddressMailbox *mailbox;
>   const char *name;
> @@ -209,40 +214,40 @@ add_recipients_for_address_list (GMimeMessage *message,
>   addr = internet_address_mailbox_get_addr (mailbox);
>  
>   if (address_is_users (addr, config)) {
> - if (ret == NULL)
> - ret = addr;
> - } else {
> + if (user_from && *user_from == NULL)
> + *user_from = addr;
> + } else if (message) {
>   g_mime_message_add_recipient (message, type, name, addr);
> + n++;
>   }
>   }
>  }
>  
> -return ret;
> +return n;
>  }
>  
> -/* For each address in 'recipients' that is not configured as one of
> - * the user's addresses in 'config', add that address to 'message' as
> - * an address of 'type'.
> +/* Scan addresses in 'recipients'.
>   *
> - * The first address encountered that *is* the user's address will be
> - * returned, (otherwise NULL is returned).
> + * See the documentation of scan_address_list() above. This function does
> + * exactly the same, but converts 'recipients' to an InternetAddressList 
> first.

Just bikeshedding, but comments in the notmuch codebase almost
universally wrap at 72 columns, not 80 (based on 
egrep '[ /]\* .{70}' *.[ch]*)

>   */
> -static const char *
> -add_recipients_for_string (GMimeMessage *message,
> -notmuch_config_t *config,
> -GMimeRecipientType type,
> -const char *recipients)
> +static unsigned int
> +scan_address_string (const char *recipients,
> +  notmuch_config_t *config,
> +  GMimeMessage *message,
> +  GMimeRecipientType type,
> +  const char **user_from)
>  {
>  InternetAddressList *list;
>  
>  if (recipients == 

[PATCH 2/2] notmuch-reply.c: uncrustify

[Tomi Ollila]

On Thu, 12 Jan 2012 09:08:18 -0400, David Bremner  wrote:
> 
> > All of the other format fixes look very reasonable to me.  I think you
> > managed to find one of the least canonical source files in the tree.
> > Was that intentional?
> 
> Yes, I expect there would be less changes elsewhere. Although the
> changes might be more controversial, I guess. 
> 
> The corresponding diff for notmuch-search.c follows
> 
> diff --git a/notmuch-search.c b/notmuch-search.c

[ ... ]
> @@ -122,7 +122,7 @@ sanitize_string (const void *ctx, const char *str)
>  loop = out = talloc_strdup (ctx, str);
>  
>  for (; *loop; loop++) {
> - if ((unsigned char)(*loop) < 32)
> + if ((unsigned char) (*loop) < 32)
>   *loop = '?';

Should (cast) be concatenated without space to the castee

>  }
>  return out;
> @@ -160,7 +160,7 @@ format_item_id_json (const void *ctx,
>  printf ("%s", json_quote_str (ctx_quote, item_id));
>  
>  talloc_free (ctx_quote);
> -
> +

Whee, whitespace-cleanup !

>  }
>  
[ ... ]


Tomi

[PATCH 4/4] emacs: Use the new JSON reply format.

[Tomi Ollila]

On Thu, 12 Jan 2012 12:07:40 +, David Edmondson  wrote:
> On Thu, 12 Jan 2012 12:33:58 +0400, Dmitry Kurochkin  gmail.com> wrote:
> > I did not follow the rest of the discussion, so sorry if I missed
> > something obvious.  But why can't we render HTML parts in replies the
> > same way we do in notmuch-show (using `mm-display-part')?  That should
> > not introduce a w3m.el requirement, would use the same renderer as
> > configured for show and hence would produce consistent output in show
> > and reply.
> 
> Agreed, that would be good. It could be done as a second stage, though.

For the record. I built emacs 23.3 from source and after installation
by default there is no w3m module available.

Related thing: by default the value of (emacs variable)
mm-text-html-renderer is resolved as follows (IIRC):

   if w3m module can be loaded value will be 'w3m
   if no w3m is available but w3m binary exists, value will be 'w3m-standalone
   else it gets some other value (if any).

Tomi

[PATCH v3 4/4] test: add tests for "notmuch reply" --reply-to=sender

[Tomi Ollila]

On Wed, 11 Jan 2012 22:50:32 -0500, Austin Clements  wrote:
> I'm not sure what the point of the last test is, but this patch
> covered everything I could think of, so LGTM.

Maybe checking that long subject line (possibly split/join sometimes in the
process) keeps it's original form (?)

LGTM (and my opinion is that 'r' in emacs is changed to 'reply-to-sender'
-- more consistent with other clients and less error prone to use (note
that I've voted this already so this doesn't increase vote count there)). 

Tomi

[PATCH] notmuch/emacs: Observe the charset of encoded parts, where known.

[David Edmondson]

On Thu, 12 Jan 2012 18:17:44 +0400, Dmitry Kurochkin  wrote:
> I think there is a record of useful features and fixes that were not
> accepted to notmuch because of some implementation issues.  And
> interested people were using them in private repos for years.  (I do not
> say that it is always the right thing to do, or that it is the right
> thing in this particular case.)

I agree that this has happened. I think that it's a failure of the
project that it has become common, necessary and generally accepted.

> I would like to see the following changes:
> 
> * Properly handle charset with parameters in Emacs UI.  Currently it is
>   broken by your patch in one place at least:
>   `notmuch-show-handlers-for' would produce incorrect results for
>   content-type string with parameters.  In my patch [1] I did parse the
>   charset at top level and then changed all usages of it accordingly.
>   Making `notmuch-show-handlers-for' smarter about parameters may be
>   sufficient, but I would like to see some more details on why adding
>   parameters to content-type string does not break Emacs UI code in
>   other places.

Your patch modifies the output of 'notmuch show' such that it included
the full value of the content-type header, which means that it is
necessary to parse it more carefully in emacs to discover and (as
necessary) remove the parameters. The patch I posted doesn't do this,
preferring to pass the charset (if any) as a supplementary parameter and
leave the content-type as-is. This distinction means that the patch I
posted isn't broken in the way that you describe.

> * Add charset parameter for text/html parts only.

Version 2 of the patch does this.

> * Use `mail-header-parse-content-type' to parse content-type instead of
>   contructing the list for `mm-make-handle' manually.

That's not required, see above.

> * Add a proper XXX comment to notmuch-show code.

I'm happy to do that.

> I cannot say I would be happy about this patch after these changes.

Can you say why? I agree that it is not a solution to all problems, but
it is a workable solution to a specific problem.

> It would be a temporary hack anyway.

Agreed. Do you have any idea when you might be able to spend time on the
better approach?
-- 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/20120112/13e6dd87/attachment.pgp>

Regarding notmuch and Fedora 16

[Tomi Ollila]

On Tue, 03 Jan 2012 22:36:59 +, Darren McGuicken  wrote:
> On Tue, 03 Jan 2012 17:09:39 -0500, Peter Portante  gmail.com> wrote:
> > I am interested in using notmuch from within emacs, but have not been 
> > able to get the latest version of notmuch (0.10.2) to compile under 
> > Fedora 16.
> 
> Looks like we have a growing Fedora community, yay! :-)
> 
> And it's nothing you're doing wrong, per my reply to the other thread
> F16 is using the current development version of gmime which has API
> differences with the stable version 2.4.  The patch that exists isn't
> part of standard notmuch since it in turn breaks 2.4 compatibility.
> 
> What's the right way to handle this?  I see 2.6 tarballs on gnome... is
> 2.6 officially out there and stable?

Some conditional compilation by #if(def)ing some *GMIME* macro...

While doing something else I passed by these messages:

http://www.mail-archive.com/notmuch at notmuchmail.org/msg05829.html
http://koji.fedoraproject.org/koji/buildinfo?buildID=269819

These seems to provide valuable information to anyone attempting
to compile notmuch with gmime 2.5+

Tomi

[PATCH v2] notmuch/emacs: Observe the charset of text/html parts, where known.

[Austin Clements]

Quoth David Edmondson on Jan 12 at  1:31 pm:
> Add the charset of text/html parts to the JSON output of 'notmuch
> -show' when it is known. Observe the encoding when rendering such
> parts in emacs.

This seems like a fine interim solution to me, though I'd like to see
a comment above the change in format_part_content_json explaining why
we include the content charset for text/html and not for anything
else.  Perhaps something like,

/* For non-HTML text/* parts, we include the content in the JSON.
 * Since JSON must be Unicode, we handle charset decoding here and do
 * not report a charset to the caller.  For text/html parts, we do not
 * include the content.  If a caller is interested in text/html parts,
 * it should retrieve them separately.  Since this makes charset
 * decoding the responsibility on the caller, we report the charset
 * for text/html parts. */

[PATCH 4/4] emacs: Use the new JSON reply format.

[David Edmondson]

On Thu, 12 Jan 2012 15:36:07 +0200, Tomi Ollila  wrote:
> On Thu, 12 Jan 2012 12:07:40 +, David Edmondson  wrote:
> > On Thu, 12 Jan 2012 12:33:58 +0400, Dmitry Kurochkin  > gmail.com> wrote:
> > > I did not follow the rest of the discussion, so sorry if I missed
> > > something obvious.  But why can't we render HTML parts in replies the
> > > same way we do in notmuch-show (using `mm-display-part')?  That should
> > > not introduce a w3m.el requirement, would use the same renderer as
> > > configured for show and hence would produce consistent output in show
> > > and reply.
> > 
> > Agreed, that would be good. It could be done as a second stage, though.
> 
> For the record. I built emacs 23.3 from source and after installation
> by default there is no w3m module available.

Currently it's broken for everyone. With the proposed changes it will be
fixed for some people. Further improvements will, of course, be
possible.
-- 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/20120112/47b4fc2d/attachment.pgp>

[PATCH v2] notmuch/emacs: Observe the charset of text/html parts, where known.

[David Edmondson]

Add the charset of text/html parts to the JSON output of 'notmuch
-show' when it is known. Observe the encoding when rendering such
parts in emacs.
---

Add the charset only for text/html parts to avoid incorrectly
declaring the charset for JSON inline text/plain parts (as they have
already been converted to UTF-8).

 emacs/notmuch-show.el |3 ++-
 notmuch-show.c|   19 ++-
 2 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 5502efd..0354a8e 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -328,7 +328,8 @@ message at DEPTH in the current thread."
 current buffer, if possible."
   (let ((display-buffer (current-buffer)))
 (with-temp-buffer
-  (let ((handle (mm-make-handle (current-buffer) (list content-type
+  (let* ((charset (plist-get part :content-charset))
+(handle (mm-make-handle (current-buffer) `(,content-type (charset 
. ,charset)
(if (and (mm-inlinable-p handle)
 (mm-inlined-p handle))
(let ((content (notmuch-show-get-bodypart-content msg part nth)))
diff --git a/notmuch-show.c b/notmuch-show.c
index 0200b9c..3d05da5 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -675,13 +675,22 @@ format_part_content_json (GMimeObject *part)
printf (", \"filename\": %s", json_quote_str (ctx, filename));
 }

-if (g_mime_content_type_is_type (content_type, "text", "*") &&
-   !g_mime_content_type_is_type (content_type, "text", "html"))
+if (g_mime_content_type_is_type (content_type, "text", "*"))
 {
-   show_text_part_content (part, stream_memory);
-   part_content = g_mime_stream_mem_get_byte_array (GMIME_STREAM_MEM 
(stream_memory));
+   if (g_mime_content_type_is_type (content_type, "text", "html"))
+   {
+   const char *content_charset = 
g_mime_object_get_content_type_parameter (GMIME_OBJECT (part), "charset");
+
+   if (content_charset != NULL)
+   printf (", \"content-charset\": %s", json_quote_str (ctx, 
content_charset));
+   }
+   else
+   {
+   show_text_part_content (part, stream_memory);
+   part_content = g_mime_stream_mem_get_byte_array (GMIME_STREAM_MEM 
(stream_memory));

-   printf (", \"content\": %s", json_quote_chararray (ctx, (char *) 
part_content->data, part_content->len));
+   printf (", \"content\": %s", json_quote_chararray (ctx, (char *) 
part_content->data, part_content->len));
+   }
 }
 else if (g_mime_content_type_is_type (content_type, "multipart", "*"))
 {
-- 
1.7.7.3

[PATCH 2/2] notmuch-reply.c: uncrustify

[Jani Nikula]

On Thu, 12 Jan 2012 09:08:18 -0400, David Bremner  wrote:
> The corresponding diff for notmuch-search.c follows

> - 
> - notmuch_filenames_destroy( filenames );
> +
> + notmuch_filenames_destroy ( filenames );

Can you make it remove the extra spaces after ( and before ) too?


BR,
Jani.

[PATCH 4/4] emacs: Use the new JSON reply format.

[Dmitry Kurochkin]

Hi Adam.

On Mon, 9 Jan 2012 19:10:48 -0700, Adam Wolfe Gordon  wrote:
> Hi David,
> 
> Thanks for the review.  Most of the things you've suggested are easy
> changes, and I think obvious improvements, so I'll change them for the
> next version.  A bit of discussion on the more involved things below:
> 
> On Mon, Jan 9, 2012 at 01:50, David Edmondson  wrote:
> > On Sun, ?8 Jan 2012 00:52:42 -0700, Adam Wolfe Gordon  > xvx.ca> wrote:
> >> +(defun w3m-region (start end)) ;; From `w3m.el'.
> >> +(defun notmuch-mua-quote-part (part)
> >> + ?(with-temp-buffer
> >> + ? ?(insert part)
> >> + ? ?(message-mode)
> >> + ? ?(fill-region (point-min) (point-max))
> >> + ? ?(goto-char (point-min))
> >> + ? ?(perform-replace "^" "> " nil t nil)
> >> + ? ?(set-buffer-modified-p nil)
> >> + ? ?(buffer-substring (point-min) (point-max
> >
> > Couldn't all of this be done directly in the reply buffer?
> 
> Indeed, it could, I just hadn't thought of it.  I'll do this for the
> next version.
> 
> > Using w3m means that you should `require' it. What happens when a user
> > doesn't have it? (Either the elisp or the command.)
> 
> This was my initial thought, but when I looked at notmuch-show.el,
> which uses w3m features, I noticed that it doesn't have a require.  To
> be clear, this patch requires w3m.el (not just the w3m binary), which
> I don't think anything else in notmuch does.
> 
> In the previous version I had a customize variable specifying whether
> to quote HTML parts, which meant that if the user could set the
> customize variable to false and everything would work without w3m.el.
> I'd like not to introduce a new prerequisite, so if there's a way to
> make w3m.el optional that would be my preference.  Can you provide
> some guidance on this?
> 

I did not follow the rest of the discussion, so sorry if I missed
something obvious.  But why can't we render HTML parts in replies the
same way we do in notmuch-show (using `mm-display-part')?  That should
not introduce a w3m.el requirement, would use the same renderer as
configured for show and hence would produce consistent output in show
and reply.

Regards,
  Dmitry

> -- 
> Adam Wolfe Gordon
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] Output unmodified Content-Type header value for JSON format.

[Austin Clements]

Quoth Pieter Praet on Jan 12 at  6:07 pm:
> On Tue, 22 Nov 2011 22:40:21 -0500, Austin Clements  
> wrote:
> > Quoth Jameson Graef Rollins on Nov 20 at 12:10 pm:
> > > The open question seems to be how we handle the content encoding
> > > parameters.  My argument is that those should either be used by notmuch
> > > to properly encode the content for the consumer.  If that's not
> > > possible, then just those parameters needed by the consumer to decode
> > > the content should be output.
> > 
> > If notmuch is going to include part content in the JSON output (which
> > perhaps it shouldn't, as per recent IRC discussions), then it must
> > handle content encodings because JSON must be Unicode and therefore
> > the content strings in the JSON must be Unicode.
> 
> Having missed the IRC discussions: what is the rationale for not
> including (specific types of?) part content in the JSON output ?
> Eg. how about inline attached text/x-patch ?

Technically the IRC discussion was about not including *any* part
content in the JSON output, and always using show --format=raw or
similar to retrieve desired parts.  Currently, notmuch includes part
content in the JSON only for text/*, *except* when it's text/html.  I
assume non-text parts are omitted because binary data is hard to
represent in JSON and text/html is omitted because some people don't
need it.  However, this leads to some peculiar asymmetry in the Emacs
code where sometimes it pulls part content out of the JSON and
sometimes it retrieves it using show --format=raw.  This in turn leads
to asymmetry in content encoding handling, since notmuch handles
content encoding for parts included in the JSON (and there's no good
way around that since JSON is Unicode), but not for parts retrieved as
raw.

The idea discussed on IRC was to remove all part content from the JSON
output and to always use show to retrieve it, possibly beefing up
show's support for content decoding (and possibly introducing a way to
retrieve multiple raw parts at once to avoid re-parsing).  This would
get the JSON format out of the business of guessing what consumers
need, simplify the Emacs code, and normalize content encoding
handling.

[PATCH 4/4] emacs: Use the new JSON reply format.

[David Edmondson]

On Thu, 12 Jan 2012 12:33:58 +0400, Dmitry Kurochkin  wrote:
> I did not follow the rest of the discussion, so sorry if I missed
> something obvious.  But why can't we render HTML parts in replies the
> same way we do in notmuch-show (using `mm-display-part')?  That should
> not introduce a w3m.el requirement, would use the same renderer as
> configured for show and hence would produce consistent output in show
> and reply.

Agreed, that would be good. It could be done as a second stage, though.
-- 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/20120112/dbfcbfad/attachment.pgp>

[PATCH] make (kill-emacs) from emacsclient work with emacs 23.(1|2)

[Austin Clements]

Quoth Tomi Ollila on Jan 12 at 10:51 am:
> On Wed, 11 Jan 2012 23:13:44 -0500, Austin Clements  
> wrote:
> > This is important to fix, but this solution seems needlessly
> > roundabout.  What about using an after-advice and simply delq'ing
> > whatever the offending hook is?  That wouldn't even need a version
> > check.
> 
> delq could work -- thanks for the idea -- but removing the hook was
> wrong shot from my part (the hook removes the cleanup I mentioned in
> one of my previous mails).

Ah, interesting.

> To minimise behaviour changes (to zero in emacs 23.3+) to minimal
> in 23.(1|2) my next suggestion goes along lines:
> 
> ;; Work around a bug in emacs 23.1 and emacs 23.2 which prevents
> ;; noninteractive (kill-emacs) from emacsclient.
> (when (and (= emacs-major-version 23) (< emacs-minor-version 3))
>   (defadvice kill-emacs (before disable-yes-or-no-p)
> "Disable yes-or-no-p before executing kill-emacs"
> (defun yes-or-no-p (prompt) t))
>   (ad-activate 'kill-emacs))

This seems reasonable.  You could shorten it a bit by changing
  (before disable-yes-or-no-p)
to
  (before disable-yes-or-no-p activate)
rather than calling ad-activate, but that's just a nit.

> Now just (accidental) additions which use yes-or-no-p 
> into kill-emacs-hook are not noticed in emacs 23.1 & 23.2.
> 
> 
> Tomi

[PATCH] notmuch/emacs: Observe the charset of encoded parts, where known.

[David Edmondson]

On Wed, 11 Jan 2012 22:34:45 +0400, Dmitry Kurochkin  wrote:
> -1

Which puts me back to 0 :-(

> One particular issue with your patch is that it adds (incorrect) charset
> parameter to plain/text parts which are converted to UTF-8 in JSON
> output.

Patches that break things should obviously not be accepted...

> I already tried to solve the above problem using a more general approach
> (output all content-type parameters, not just charset) [1].  There was a
> lengthy discussion on IRC about it and it was rejected.  The consensus
> was that we need to make some more substantial changes to JSON and raw
> output formats to properly fix the issue (and the issue is more general
> than what this patch fixes, other content-type parameters are useful for
> renderers as well and should be included in the output).

...but a useful point fix should not be blocked by theoretical future
work.

> I am planning to work on a proper fix for this issue, but decided to
> postpone it until Austin's rewrite of notmuch show is complete.

If the UTF8 text/plain part issue can be resolved, would you be happier
to accept this as an interim fix whilst we wait for the more complete
solution?

Nothing in the patch (so far) should make your proposed changes any
harder, so I'm not sure what the problem would be.
-- 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/20120112/bc4f9c7c/attachment.pgp>

Emacs: Crypto: How to get automatic encryption?

[Jameson Graef Rollins]

On Thu, 12 Jan 2012 20:05:14 +0100, Gregor Zattler  wrote:
> But how about not only replying encrypted but encrypting every
> email if possible?  "Possible" could mean different things,
> though:

This is already easy to do in emacs, and doesn't require any special
notmuch support:

(add-hook 'message-setup-hook mml-secure-message-encrypt-pgpmime)

This is the same as what I suggested for auto-sign.  You might have to
do a little elisp hacking to do fancier stuff, but again, doing
something for all outgoing mail is more about message-mode, and is not
notmuch specific.

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/20120112/c4582fc9/attachment.pgp>

[PATCH] make (kill-emacs) from emacsclient work with emacs 23.(1|2)

[Tomi Ollila]

On Wed, 11 Jan 2012 23:13:44 -0500, Austin Clements  wrote:
> This is important to fix, but this solution seems needlessly
> roundabout.  What about using an after-advice and simply delq'ing
> whatever the offending hook is?  That wouldn't even need a version
> check.

delq could work -- thanks for the idea -- but removing the hook was
wrong shot from my part (the hook removes the cleanup I mentioned in
one of my previous mails).

To minimise behaviour changes (to zero in emacs 23.3+) to minimal
in 23.(1|2) my next suggestion goes along lines:

;; Work around a bug in emacs 23.1 and emacs 23.2 which prevents
;; noninteractive (kill-emacs) from emacsclient.
(when (and (= emacs-major-version 23) (< emacs-minor-version 3))
  (defadvice kill-emacs (before disable-yes-or-no-p)
"Disable yes-or-no-p before executing kill-emacs"
(defun yes-or-no-p (prompt) t))
  (ad-activate 'kill-emacs))

Now just (accidental) additions which use yes-or-no-p 
into kill-emacs-hook are not noticed in emacs 23.1 & 23.2.


Tomi

Emacs: Crypto: How to get automatic encryption?

[Jameson Graef Rollins]

On Tue, 03 Jan 2012 13:45:14 -0800, Jameson Graef Rollins  wrote:
> Unfortunately, auto encrypting of replies to encrypted emails is not yet
> implemented.  It is desperately needed, though, obviously.  So this is a
> good excuse to start a discussion about how we could achieve this.
> 
> It just occurs to me that a way to do this would be to have notmuch
> reply add the appropriate mml #secure tag for encryption to the output
> reply template, maybe with something like a --emacs option.  That would
> be pretty easy to implement, although it would obviously be very UI
> specific.
> 
> Another possibility would be for notmuch reply to add some sort of
> header to the reply message to indicate that the original was encrypted,
> and then do something in emacs to try to read that header and add the
> appropriate mml #secure tag.  That would also be easy to implement in
> the notmuch CLI, and it would be more UI agnostic, but it would require
> a lot more elisp.

There is a set of patches in the queue to add a JSON output format for
reply, with the emacs UI then consuming that to construct the reply
template [0].  This will make it very easy to communicate to the emacs
UI that the original message was encrypted, and that the reply should be
similarly encrypted.  I'm going to wait until that patch set makes it
through, and then build this functionality on top of that.

jamie.

[0] id:"1326009162-19524-3-git-send-email-awg+notmuch at xvx.ca"
-- 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/20120112/42337ce5/attachment.pgp>

[PATCH 2/2] notmuch-reply.c: uncrustify

[Austin Clements]

Quoth David Bremner on Jan 12 at  9:08 am:
> @@ -425,7 +420,7 @@ notmuch_search_command (void *ctx, int argc, char *argv[])
>  int limit = -1; /* unlimited */
>  
>  enum { NOTMUCH_FORMAT_JSON, NOTMUCH_FORMAT_TEXT }
> - format_sel = NOTMUCH_FORMAT_TEXT;
> +format_sel = NOTMUCH_FORMAT_TEXT;

This is unfortunate, but other than the format structure flattening,
the remaining changes look reasonable to me.

>  
>  notmuch_opt_desc_t options[] = {
>   { NOTMUCH_OPT_KEYWORD, , "sort", 's',

[PATCH 2/2] notmuch-reply.c: uncrustify

[David Bremner]

On Wed, 11 Jan 2012 22:57:39 -0500, Austin Clements  wrote:
> > From: David Bremner 
> > 
> > This patch shows the raw result of running uncrustify on notmuch-reply.c.
> > The re-indenting of "format_reply" would probably not be desirable.
> 
> The good news is that that structure is on its way out.
> 
> > @@ -625,6 +612,7 @@ notmuch_reply_command (void *ctx, int argc, char 
> > *argv[])
> >  notmuch_query_t *query;
> >  char *query_string;
> >  int opt_index, ret = 0;
> > +
> 
> This one's a little weird.  Did it get confused by the function
> prototype?

Yes, I think it is thinking the block of variable declarations ends
there.

> All of the other format fixes look very reasonable to me.  I think you
> managed to find one of the least canonical source files in the tree.
> Was that intentional?

Yes, I expect there would be less changes elsewhere. Although the
changes might be more controversial, I guess. 

The corresponding diff for notmuch-search.c follows

diff --git a/notmuch-search.c b/notmuch-search.c
index 4baab56..8928e62 100644
--- a/notmuch-search.c
+++ b/notmuch-search.c
@@ -31,16 +31,16 @@ typedef enum {
 typedef struct search_format {
 const char *results_start;
 const char *item_start;
-void (*item_id) (const void *ctx,
-const char *item_type,
-const char *item_id);
-void (*thread_summary) (const void *ctx,
-   const char *thread_id,
-   const time_t date,
-   const int matched,
-   const int total,
-   const char *authors,
-   const char *subject);
+void (*item_id)(const void *ctx,
+   const char *item_type,
+   const char *item_id);
+void (*thread_summary)(const void *ctx,
+  const char *thread_id,
+  const time_t date,
+  const int matched,
+  const int total,
+  const char *authors,
+  const char *subject);
 const char *tag_start;
 const char *tag;
 const char *tag_sep;
@@ -66,13 +66,13 @@ format_thread_text (const void *ctx,
const char *subject);
 static const search_format_t format_text = {
 "",
-   "",
-   format_item_id_text,
-   format_thread_text,
-   " (",
-   "%s", " ",
-   ")", "\n",
-   "",
+"",
+format_item_id_text,
+format_thread_text,
+" (",
+"%s", " ",
+")", "\n",
+"",
 "\n",
 "",
 };
@@ -92,13 +92,13 @@ format_thread_json (const void *ctx,
const char *subject);
 static const search_format_t format_json = {
 "[",
-   "{",
-   format_item_id_json,
-   format_thread_json,
-   "\"tags\": [",
-   "\"%s\"", ", ",
-   "]", ",\n",
-   "}",
+"{",
+format_item_id_json,
+format_thread_json,
+"\"tags\": [",
+"\"%s\"", ", ",
+"]", ",\n",
+"}",
 "]\n",
 "]\n",
 };
@@ -122,7 +122,7 @@ sanitize_string (const void *ctx, const char *str)
 loop = out = talloc_strdup (ctx, str);

 for (; *loop; loop++) {
-   if ((unsigned char)(*loop) < 32)
+   if ((unsigned char) (*loop) < 32)
*loop = '?';
 }
 return out;
@@ -160,7 +160,7 @@ format_item_id_json (const void *ctx,
 printf ("%s", json_quote_str (ctx_quote, item_id));

 talloc_free (ctx_quote);
-
+
 }

 static void
@@ -221,8 +221,7 @@ do_search_threads (const search_format_t *format,

 for (i = 0;
 notmuch_threads_valid (threads) && (limit < 0 || i < offset + limit);
-notmuch_threads_move_to_next (threads), i++)
-{
+notmuch_threads_move_to_next (threads), i++) {
int first_tag = 1;

thread = notmuch_threads_get (threads);
@@ -232,7 +231,7 @@ do_search_threads (const search_format_t *format,
continue;
}

-   if (! first_thread)
+   if (!first_thread)
fputs (format->item_sep, stdout);

if (output == OUTPUT_THREADS) {
@@ -258,9 +257,8 @@ do_search_threads (const search_format_t *format,

for (tags = notmuch_thread_get_tags (thread);
 notmuch_tags_valid (tags);
-notmuch_tags_move_to_next (tags))
-   {
-   if (! first_tag)
+notmuch_tags_move_to_next (tags)) {
+   if (!first_tag)
fputs (format->tag_sep, stdout);
printf (format->tag, notmuch_tags_get (tags));
first_tag = 0;
@@ -311,8 +309,7 @@ do_search_messages (const search_format_t *format,

 for (i = 0;
 notmuch_messages_valid (messages) && (limit < 0 || i < offset + limit);
-notmuch_messages_move_to_next (messages), i++)
-{
+notmuch_messages_move_to_next 

[PATCH v3 2/4] emacs: add support for replying just to the sender

[Jani Nikula]

On Wed, 11 Jan 2012 16:15:30 -0500, Aaron Ecay  wrote:
> On Wed, 11 Jan 2012 08:20:56 +, David Edmondson  wrote:
> > On Tue, 10 Jan 2012 21:54:02 +0200, Jani Nikula  wrote:
> > > -(defun notmuch-mua-reply (query-string  sender)
> > > +(defun notmuch-mua-reply (query-string  sender reply-all)
> > >(let (headers
> > >   body
> > >   (args '("reply")))
> > >  (if notmuch-show-process-crypto
> > >   (setq args (append args '("--decrypt"
> > > +(if reply-all
> > > + (setq args (append args '("--reply-to=all")))
> > > +  (setq args (append args '("--reply-to=sender"
> > >  (setq args (append args (list query-string)))
> > 
> > I don't like how this ends up. How about something like:
> > 
> > (defun notmuch-mua-reply (query-string  sender)
> >   (let (headers
> > body
> > (args (nconc (list "reply"
> >(concat "--reply-to="
> >(if reply-all "all" "sender")))
> >  (when notmuch-show-process-crypto
> >(list "--decrypt"))
> >  (list query-string
> 
> What about using ?format?:
> 
> (let (...
>   (args (format "reply --reply-to=%s %s %s"
> (if reply-all "all" "sender")
> (if notmuch-show-process-crypto "--decrypt" "")
> query-string)))
>   ...)
> 
> It?s still not beautiful, but maybe it is better?

I don't think it works. The arguments to call-process need to be a list,
not a string.

BR,
Jani.

Re: [PATCH 4/4] emacs: Use the new JSON reply format.

[Dmitry Kurochkin]

Hi Adam.

On Mon, 9 Jan 2012 19:10:48 -0700, Adam Wolfe Gordon a...@xvx.ca wrote:
 Hi David,
 
 Thanks for the review.  Most of the things you've suggested are easy
 changes, and I think obvious improvements, so I'll change them for the
 next version.  A bit of discussion on the more involved things below:
 
 On Mon, Jan 9, 2012 at 01:50, David Edmondson d...@dme.org wrote:
  On Sun,  8 Jan 2012 00:52:42 -0700, Adam Wolfe Gordon awg+notm...@xvx.ca 
  wrote:
  +(defun w3m-region (start end)) ;; From `w3m.el'.
  +(defun notmuch-mua-quote-part (part)
  +  (with-temp-buffer
  +    (insert part)
  +    (message-mode)
  +    (fill-region (point-min) (point-max))
  +    (goto-char (point-min))
  +    (perform-replace ^   nil t nil)
  +    (set-buffer-modified-p nil)
  +    (buffer-substring (point-min) (point-max
 
  Couldn't all of this be done directly in the reply buffer?
 
 Indeed, it could, I just hadn't thought of it.  I'll do this for the
 next version.
 
  Using w3m means that you should `require' it. What happens when a user
  doesn't have it? (Either the elisp or the command.)
 
 This was my initial thought, but when I looked at notmuch-show.el,
 which uses w3m features, I noticed that it doesn't have a require.  To
 be clear, this patch requires w3m.el (not just the w3m binary), which
 I don't think anything else in notmuch does.
 
 In the previous version I had a customize variable specifying whether
 to quote HTML parts, which meant that if the user could set the
 customize variable to false and everything would work without w3m.el.
 I'd like not to introduce a new prerequisite, so if there's a way to
 make w3m.el optional that would be my preference.  Can you provide
 some guidance on this?
 

I did not follow the rest of the discussion, so sorry if I missed
something obvious.  But why can't we render HTML parts in replies the
same way we do in notmuch-show (using `mm-display-part')?  That should
not introduce a w3m.el requirement, would use the same renderer as
configured for show and hence would produce consistent output in show
and reply.

Regards,
  Dmitry

 -- 
 Adam Wolfe Gordon
 ___
 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] make (kill-emacs) from emacsclient work with emacs 23.(1|2)

[Tomi Ollila]

On Wed, 11 Jan 2012 23:13:44 -0500, Austin Clements amdra...@mit.edu wrote:
 This is important to fix, but this solution seems needlessly
 roundabout.  What about using an after-advice and simply delq'ing
 whatever the offending hook is?  That wouldn't even need a version
 check.

delq could work -- thanks for the idea -- but removing the hook was
wrong shot from my part (the hook removes the cleanup I mentioned in
one of my previous mails).

To minimise behaviour changes (to zero in emacs 23.3+) to minimal
in 23.(1|2) my next suggestion goes along lines:

;; Work around a bug in emacs 23.1 and emacs 23.2 which prevents
;; noninteractive (kill-emacs) from emacsclient.
(when (and (= emacs-major-version 23) ( emacs-minor-version 3))
  (defadvice kill-emacs (before disable-yes-or-no-p)
Disable yes-or-no-p before executing kill-emacs
(defun yes-or-no-p (prompt) t))
  (ad-activate 'kill-emacs))

Now just (accidental) additions which use yes-or-no-p 
into kill-emacs-hook are not noticed in emacs 23.1  23.2.


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

Re: [PATCH] notmuch/emacs: Observe the charset of encoded parts, where known.

[David Edmondson]

On Wed, 11 Jan 2012 22:34:45 +0400, Dmitry Kurochkin 
dmitry.kuroch...@gmail.com wrote:
 -1

Which puts me back to 0 :-(

 One particular issue with your patch is that it adds (incorrect) charset
 parameter to plain/text parts which are converted to UTF-8 in JSON
 output.

Patches that break things should obviously not be accepted...

 I already tried to solve the above problem using a more general approach
 (output all content-type parameters, not just charset) [1].  There was a
 lengthy discussion on IRC about it and it was rejected.  The consensus
 was that we need to make some more substantial changes to JSON and raw
 output formats to properly fix the issue (and the issue is more general
 than what this patch fixes, other content-type parameters are useful for
 renderers as well and should be included in the output).

...but a useful point fix should not be blocked by theoretical future
work.

 I am planning to work on a proper fix for this issue, but decided to
 postpone it until Austin's rewrite of notmuch show is complete.

If the UTF8 text/plain part issue can be resolved, would you be happier
to accept this as an interim fix whilst we wait for the more complete
solution?

Nothing in the patch (so far) should make your proposed changes any
harder, so I'm not sure what the problem would be.


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

Re: [PATCH 4/4] emacs: Use the new JSON reply format.

[David Edmondson]

On Thu, 12 Jan 2012 12:33:58 +0400, Dmitry Kurochkin 
dmitry.kuroch...@gmail.com wrote:
 I did not follow the rest of the discussion, so sorry if I missed
 something obvious.  But why can't we render HTML parts in replies the
 same way we do in notmuch-show (using `mm-display-part')?  That should
 not introduce a w3m.el requirement, would use the same renderer as
 configured for show and hence would produce consistent output in show
 and reply.

Agreed, that would be good. It could be done as a second stage, though.


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

Re: Regarding notmuch and Fedora 16

[Tomi Ollila]

On Tue, 03 Jan 2012 22:36:59 +, Darren McGuicken 
mailing-notm...@fernseed.info wrote:
 On Tue, 03 Jan 2012 17:09:39 -0500, Peter Portante 
 peter.a.porta...@gmail.com wrote:
  I am interested in using notmuch from within emacs, but have not been 
  able to get the latest version of notmuch (0.10.2) to compile under 
  Fedora 16.
 
 Looks like we have a growing Fedora community, yay! :-)
 
 And it's nothing you're doing wrong, per my reply to the other thread
 F16 is using the current development version of gmime which has API
 differences with the stable version 2.4.  The patch that exists isn't
 part of standard notmuch since it in turn breaks 2.4 compatibility.
 
 What's the right way to handle this?  I see 2.6 tarballs on gnome... is
 2.6 officially out there and stable?

Some conditional compilation by #if(def)ing some *GMIME* macro...

While doing something else I passed by these messages:

http://www.mail-archive.com/notmuch@notmuchmail.org/msg05829.html
http://koji.fedoraproject.org/koji/buildinfo?buildID=269819

These seems to provide valuable information to anyone attempting
to compile notmuch with gmime 2.5+

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

Re: [PATCH v3 4/4] test: add tests for notmuch reply --reply-to=sender

[Tomi Ollila]

On Wed, 11 Jan 2012 22:50:32 -0500, Austin Clements amdra...@mit.edu wrote:
 I'm not sure what the point of the last test is, but this patch
 covered everything I could think of, so LGTM.

Maybe checking that long subject line (possibly split/join sometimes in the
process) keeps it's original form (?)

LGTM (and my opinion is that 'r' in emacs is changed to 'reply-to-sender'
-- more consistent with other clients and less error prone to use (note
that I've voted this already so this doesn't increase vote count there)). 

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

Re: [PATCH 2/2] notmuch-reply.c: uncrustify

[David Bremner]

On Wed, 11 Jan 2012 22:57:39 -0500, Austin Clements amdra...@mit.edu wrote:
  From: David Bremner brem...@debian.org
  
  This patch shows the raw result of running uncrustify on notmuch-reply.c.
  The re-indenting of format_reply would probably not be desirable.
 
 The good news is that that structure is on its way out.
 
  @@ -625,6 +612,7 @@ notmuch_reply_command (void *ctx, int argc, char 
  *argv[])
   notmuch_query_t *query;
   char *query_string;
   int opt_index, ret = 0;
  +
 
 This one's a little weird.  Did it get confused by the function
 prototype?

Yes, I think it is thinking the block of variable declarations ends
there.

 All of the other format fixes look very reasonable to me.  I think you
 managed to find one of the least canonical source files in the tree.
 Was that intentional?

Yes, I expect there would be less changes elsewhere. Although the
changes might be more controversial, I guess. 

The corresponding diff for notmuch-search.c follows

diff --git a/notmuch-search.c b/notmuch-search.c
index 4baab56..8928e62 100644
--- a/notmuch-search.c
+++ b/notmuch-search.c
@@ -31,16 +31,16 @@ typedef enum {
 typedef struct search_format {
 const char *results_start;
 const char *item_start;
-void (*item_id) (const void *ctx,
-const char *item_type,
-const char *item_id);
-void (*thread_summary) (const void *ctx,
-   const char *thread_id,
-   const time_t date,
-   const int matched,
-   const int total,
-   const char *authors,
-   const char *subject);
+void (*item_id)(const void *ctx,
+   const char *item_type,
+   const char *item_id);
+void (*thread_summary)(const void *ctx,
+  const char *thread_id,
+  const time_t date,
+  const int matched,
+  const int total,
+  const char *authors,
+  const char *subject);
 const char *tag_start;
 const char *tag;
 const char *tag_sep;
@@ -66,13 +66,13 @@ format_thread_text (const void *ctx,
const char *subject);
 static const search_format_t format_text = {
 ,
-   ,
-   format_item_id_text,
-   format_thread_text,
-(,
-   %s,  ,
-   ), \n,
-   ,
+,
+format_item_id_text,
+format_thread_text,
+ (,
+%s,  ,
+), \n,
+,
 \n,
 ,
 };
@@ -92,13 +92,13 @@ format_thread_json (const void *ctx,
const char *subject);
 static const search_format_t format_json = {
 [,
-   {,
-   format_item_id_json,
-   format_thread_json,
-   \tags\: [,
-   \%s\, , ,
-   ], ,\n,
-   },
+{,
+format_item_id_json,
+format_thread_json,
+\tags\: [,
+\%s\, , ,
+], ,\n,
+},
 ]\n,
 ]\n,
 };
@@ -122,7 +122,7 @@ sanitize_string (const void *ctx, const char *str)
 loop = out = talloc_strdup (ctx, str);
 
 for (; *loop; loop++) {
-   if ((unsigned char)(*loop)  32)
+   if ((unsigned char) (*loop)  32)
*loop = '?';
 }
 return out;
@@ -160,7 +160,7 @@ format_item_id_json (const void *ctx,
 printf (%s, json_quote_str (ctx_quote, item_id));
 
 talloc_free (ctx_quote);
-
+
 }
 
 static void
@@ -221,8 +221,7 @@ do_search_threads (const search_format_t *format,
 
 for (i = 0;
 notmuch_threads_valid (threads)  (limit  0 || i  offset + limit);
-notmuch_threads_move_to_next (threads), i++)
-{
+notmuch_threads_move_to_next (threads), i++) {
int first_tag = 1;
 
thread = notmuch_threads_get (threads);
@@ -232,7 +231,7 @@ do_search_threads (const search_format_t *format,
continue;
}
 
-   if (! first_thread)
+   if (!first_thread)
fputs (format-item_sep, stdout);
 
if (output == OUTPUT_THREADS) {
@@ -258,9 +257,8 @@ do_search_threads (const search_format_t *format,
 
for (tags = notmuch_thread_get_tags (thread);
 notmuch_tags_valid (tags);
-notmuch_tags_move_to_next (tags))
-   {
-   if (! first_tag)
+notmuch_tags_move_to_next (tags)) {
+   if (!first_tag)
fputs (format-tag_sep, stdout);
printf (format-tag, notmuch_tags_get (tags));
first_tag = 0;
@@ -311,8 +309,7 @@ do_search_messages (const search_format_t *format,
 
 for (i = 0;
 notmuch_messages_valid (messages)  (limit  0 || i  offset + limit);
-notmuch_messages_move_to_next (messages), i++)
-{
+notmuch_messages_move_to_next (messages), i++) {
if (i  offset)
continue;
 
@@ -323,9 +320,8 @@ 

Re: [PATCH 2/2] notmuch-reply.c: uncrustify

[Jani Nikula]

On Thu, 12 Jan 2012 09:08:18 -0400, David Bremner da...@tethera.net wrote:
 The corresponding diff for notmuch-search.c follows

 - 
 - notmuch_filenames_destroy( filenames );
 +
 + notmuch_filenames_destroy ( filenames );

Can you make it remove the extra spaces after ( and before ) too?


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

[PATCH v2] notmuch/emacs: Observe the charset of text/html parts, where known.

[David Edmondson]

Add the charset of text/html parts to the JSON output of 'notmuch
-show' when it is known. Observe the encoding when rendering such
parts in emacs.
---

Add the charset only for text/html parts to avoid incorrectly
declaring the charset for JSON inline text/plain parts (as they have
already been converted to UTF-8).

 emacs/notmuch-show.el |3 ++-
 notmuch-show.c|   19 ++-
 2 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 5502efd..0354a8e 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -328,7 +328,8 @@ message at DEPTH in the current thread.
 current buffer, if possible.
   (let ((display-buffer (current-buffer)))
 (with-temp-buffer
-  (let ((handle (mm-make-handle (current-buffer) (list content-type
+  (let* ((charset (plist-get part :content-charset))
+(handle (mm-make-handle (current-buffer) `(,content-type (charset 
. ,charset)
(if (and (mm-inlinable-p handle)
 (mm-inlined-p handle))
(let ((content (notmuch-show-get-bodypart-content msg part nth)))
diff --git a/notmuch-show.c b/notmuch-show.c
index 0200b9c..3d05da5 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -675,13 +675,22 @@ format_part_content_json (GMimeObject *part)
printf (, \filename\: %s, json_quote_str (ctx, filename));
 }
 
-if (g_mime_content_type_is_type (content_type, text, *) 
-   !g_mime_content_type_is_type (content_type, text, html))
+if (g_mime_content_type_is_type (content_type, text, *))
 {
-   show_text_part_content (part, stream_memory);
-   part_content = g_mime_stream_mem_get_byte_array (GMIME_STREAM_MEM 
(stream_memory));
+   if (g_mime_content_type_is_type (content_type, text, html))
+   {
+   const char *content_charset = 
g_mime_object_get_content_type_parameter (GMIME_OBJECT (part), charset);
+
+   if (content_charset != NULL)
+   printf (, \content-charset\: %s, json_quote_str (ctx, 
content_charset));
+   }
+   else
+   {
+   show_text_part_content (part, stream_memory);
+   part_content = g_mime_stream_mem_get_byte_array (GMIME_STREAM_MEM 
(stream_memory));
 
-   printf (, \content\: %s, json_quote_chararray (ctx, (char *) 
part_content-data, part_content-len));
+   printf (, \content\: %s, json_quote_chararray (ctx, (char *) 
part_content-data, part_content-len));
+   }
 }
 else if (g_mime_content_type_is_type (content_type, multipart, *))
 {
-- 
1.7.7.3

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

Re: [PATCH 4/4] emacs: Use the new JSON reply format.

[Tomi Ollila]

On Thu, 12 Jan 2012 12:07:40 +, David Edmondson d...@dme.org wrote:
 On Thu, 12 Jan 2012 12:33:58 +0400, Dmitry Kurochkin 
 dmitry.kuroch...@gmail.com wrote:
  I did not follow the rest of the discussion, so sorry if I missed
  something obvious.  But why can't we render HTML parts in replies the
  same way we do in notmuch-show (using `mm-display-part')?  That should
  not introduce a w3m.el requirement, would use the same renderer as
  configured for show and hence would produce consistent output in show
  and reply.
 
 Agreed, that would be good. It could be done as a second stage, though.

For the record. I built emacs 23.3 from source and after installation
by default there is no w3m module available.

Related thing: by default the value of (emacs variable)
mm-text-html-renderer is resolved as follows (IIRC):

   if w3m module can be loaded value will be 'w3m
   if no w3m is available but w3m binary exists, value will be 'w3m-standalone
   else it gets some other value (if any).

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

Re: [PATCH 4/4] emacs: Use the new JSON reply format.

[David Edmondson]

On Thu, 12 Jan 2012 15:36:07 +0200, Tomi Ollila tomi.oll...@iki.fi wrote:
 On Thu, 12 Jan 2012 12:07:40 +, David Edmondson d...@dme.org wrote:
  On Thu, 12 Jan 2012 12:33:58 +0400, Dmitry Kurochkin 
  dmitry.kuroch...@gmail.com wrote:
   I did not follow the rest of the discussion, so sorry if I missed
   something obvious.  But why can't we render HTML parts in replies the
   same way we do in notmuch-show (using `mm-display-part')?  That should
   not introduce a w3m.el requirement, would use the same renderer as
   configured for show and hence would produce consistent output in show
   and reply.
  
  Agreed, that would be good. It could be done as a second stage, though.
 
 For the record. I built emacs 23.3 from source and after installation
 by default there is no w3m module available.

Currently it's broken for everyone. With the proposed changes it will be
fixed for some people. Further improvements will, of course, be
possible.


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

Re: [PATCH 2/2] notmuch-reply.c: uncrustify

[Tomi Ollila]

On Thu, 12 Jan 2012 09:08:18 -0400, David Bremner da...@tethera.net wrote:
 
  All of the other format fixes look very reasonable to me.  I think you
  managed to find one of the least canonical source files in the tree.
  Was that intentional?
 
 Yes, I expect there would be less changes elsewhere. Although the
 changes might be more controversial, I guess. 
 
 The corresponding diff for notmuch-search.c follows
 
 diff --git a/notmuch-search.c b/notmuch-search.c

[ ... ]
 @@ -122,7 +122,7 @@ sanitize_string (const void *ctx, const char *str)
  loop = out = talloc_strdup (ctx, str);
  
  for (; *loop; loop++) {
 - if ((unsigned char)(*loop)  32)
 + if ((unsigned char) (*loop)  32)
   *loop = '?';

Should (cast) be concatenated without space to the castee

  }
  return out;
 @@ -160,7 +160,7 @@ format_item_id_json (const void *ctx,
  printf (%s, json_quote_str (ctx_quote, item_id));
  
  talloc_free (ctx_quote);
 -
 +

Whee, whitespace-cleanup !

  }
  
[ ... ]


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

Re: [PATCH] notmuch/emacs: Observe the charset of encoded parts, where known.

[Dmitry Kurochkin]

Hi David.

On Thu, 12 Jan 2012 12:00:14 +, David Edmondson d...@dme.org wrote:
 On Wed, 11 Jan 2012 22:34:45 +0400, Dmitry Kurochkin 
 dmitry.kuroch...@gmail.com wrote:
  -1
 
 Which puts me back to 0 :-(
 
  One particular issue with your patch is that it adds (incorrect) charset
  parameter to plain/text parts which are converted to UTF-8 in JSON
  output.
 
 Patches that break things should obviously not be accepted...
 
  I already tried to solve the above problem using a more general approach
  (output all content-type parameters, not just charset) [1].  There was a
  lengthy discussion on IRC about it and it was rejected.  The consensus
  was that we need to make some more substantial changes to JSON and raw
  output formats to properly fix the issue (and the issue is more general
  than what this patch fixes, other content-type parameters are useful for
  renderers as well and should be included in the output).
 
 ...but a useful point fix should not be blocked by theoretical future
 work.
 

I think there is a record of useful features and fixes that were not
accepted to notmuch because of some implementation issues.  And
interested people were using them in private repos for years.  (I do not
say that it is always the right thing to do, or that it is the right
thing in this particular case.)

  I am planning to work on a proper fix for this issue, but decided to
  postpone it until Austin's rewrite of notmuch show is complete.
 
 If the UTF8 text/plain part issue can be resolved, would you be happier
 to accept this as an interim fix whilst we wait for the more complete
 solution?
 

I would like to see the following changes:

* Properly handle charset with parameters in Emacs UI.  Currently it is
  broken by your patch in one place at least:
  `notmuch-show-handlers-for' would produce incorrect results for
  content-type string with parameters.  In my patch [1] I did parse the
  charset at top level and then changed all usages of it accordingly.
  Making `notmuch-show-handlers-for' smarter about parameters may be
  sufficient, but I would like to see some more details on why adding
  parameters to content-type string does not break Emacs UI code in
  other places.

* Add charset parameter for text/html parts only.

* Use `mail-header-parse-content-type' to parse content-type instead of
  contructing the list for `mm-make-handle' manually.

* Add a proper XXX comment to notmuch-show code.

I cannot say I would be happy about this patch after these changes.  It
would be a temporary hack anyway.  But I would withdraw my -1 and let
others decide.  I would like to see Jameson and Austin input on this
one.

Regards,
  Dmitry

[1] id:1321659905-24367-1-git-send-email-dmitry.kuroch...@gmail.com

 Nothing in the patch (so far) should make your proposed changes any
 harder, so I'm not sure what the problem would be.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] notmuch/emacs: Observe the charset of encoded parts, where known.

[David Edmondson]

On Thu, 12 Jan 2012 18:17:44 +0400, Dmitry Kurochkin 
dmitry.kuroch...@gmail.com wrote:
 I think there is a record of useful features and fixes that were not
 accepted to notmuch because of some implementation issues.  And
 interested people were using them in private repos for years.  (I do not
 say that it is always the right thing to do, or that it is the right
 thing in this particular case.)

I agree that this has happened. I think that it's a failure of the
project that it has become common, necessary and generally accepted.

 I would like to see the following changes:
 
 * Properly handle charset with parameters in Emacs UI.  Currently it is
   broken by your patch in one place at least:
   `notmuch-show-handlers-for' would produce incorrect results for
   content-type string with parameters.  In my patch [1] I did parse the
   charset at top level and then changed all usages of it accordingly.
   Making `notmuch-show-handlers-for' smarter about parameters may be
   sufficient, but I would like to see some more details on why adding
   parameters to content-type string does not break Emacs UI code in
   other places.

Your patch modifies the output of 'notmuch show' such that it included
the full value of the content-type header, which means that it is
necessary to parse it more carefully in emacs to discover and (as
necessary) remove the parameters. The patch I posted doesn't do this,
preferring to pass the charset (if any) as a supplementary parameter and
leave the content-type as-is. This distinction means that the patch I
posted isn't broken in the way that you describe.

 * Add charset parameter for text/html parts only.

Version 2 of the patch does this.

 * Use `mail-header-parse-content-type' to parse content-type instead of
   contructing the list for `mm-make-handle' manually.

That's not required, see above.

 * Add a proper XXX comment to notmuch-show code.

I'm happy to do that.

 I cannot say I would be happy about this patch after these changes.

Can you say why? I agree that it is not a solution to all problems, but
it is a workable solution to a specific problem.

 It would be a temporary hack anyway.

Agreed. Do you have any idea when you might be able to spend time on the
better approach?


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

Re: [PATCH] notmuch/emacs: Observe the charset of encoded parts, where known.

[Dmitry Kurochkin]

On Thu, 12 Jan 2012 14:42:49 +, David Edmondson d...@dme.org wrote:
 On Thu, 12 Jan 2012 18:17:44 +0400, Dmitry Kurochkin 
 dmitry.kuroch...@gmail.com wrote:
  I think there is a record of useful features and fixes that were not
  accepted to notmuch because of some implementation issues.  And
  interested people were using them in private repos for years.  (I do not
  say that it is always the right thing to do, or that it is the right
  thing in this particular case.)
 
 I agree that this has happened. I think that it's a failure of the
 project that it has become common, necessary and generally accepted.
 
  I would like to see the following changes:
  
  * Properly handle charset with parameters in Emacs UI.  Currently it is
broken by your patch in one place at least:
`notmuch-show-handlers-for' would produce incorrect results for
content-type string with parameters.  In my patch [1] I did parse the
charset at top level and then changed all usages of it accordingly.
Making `notmuch-show-handlers-for' smarter about parameters may be
sufficient, but I would like to see some more details on why adding
parameters to content-type string does not break Emacs UI code in
other places.
 
 Your patch modifies the output of 'notmuch show' such that it included
 the full value of the content-type header, which means that it is
 necessary to parse it more carefully in emacs to discover and (as
 necessary) remove the parameters. The patch I posted doesn't do this,
 preferring to pass the charset (if any) as a supplementary parameter and
 leave the content-type as-is. This distinction means that the patch I
 posted isn't broken in the way that you describe.
 

Sorry, I should have better look at the code.

  * Add charset parameter for text/html parts only.
 
 Version 2 of the patch does this.
 
  * Use `mail-header-parse-content-type' to parse content-type instead of
contructing the list for `mm-make-handle' manually.
 
 That's not required, see above.
 
  * Add a proper XXX comment to notmuch-show code.
 
 I'm happy to do that.
 
  I cannot say I would be happy about this patch after these changes.
 
 Can you say why? I agree that it is not a solution to all problems, but
 it is a workable solution to a specific problem.
 

At the very least, because I did not really review the code, as you
probably understood from my poor comments :)

I do not have a strong preference here.  If others do, I prefer to leave
it for them to decide.

  It would be a temporary hack anyway.
 
 Agreed. Do you have any idea when you might be able to spend time on the
 better approach?

I hope to work on this once Austin's notmuch show rewrite is done.  It
is progressing, but I do not have any estimations.

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

Re: [PATCH] make (kill-emacs) from emacsclient work with emacs 23.(1|2)

[Austin Clements]

Quoth Tomi Ollila on Jan 12 at 10:51 am:
 On Wed, 11 Jan 2012 23:13:44 -0500, Austin Clements amdra...@mit.edu wrote:
  This is important to fix, but this solution seems needlessly
  roundabout.  What about using an after-advice and simply delq'ing
  whatever the offending hook is?  That wouldn't even need a version
  check.
 
 delq could work -- thanks for the idea -- but removing the hook was
 wrong shot from my part (the hook removes the cleanup I mentioned in
 one of my previous mails).

Ah, interesting.

 To minimise behaviour changes (to zero in emacs 23.3+) to minimal
 in 23.(1|2) my next suggestion goes along lines:
 
 ;; Work around a bug in emacs 23.1 and emacs 23.2 which prevents
 ;; noninteractive (kill-emacs) from emacsclient.
 (when (and (= emacs-major-version 23) ( emacs-minor-version 3))
   (defadvice kill-emacs (before disable-yes-or-no-p)
 Disable yes-or-no-p before executing kill-emacs
 (defun yes-or-no-p (prompt) t))
   (ad-activate 'kill-emacs))

This seems reasonable.  You could shorten it a bit by changing
  (before disable-yes-or-no-p)
to
  (before disable-yes-or-no-p activate)
rather than calling ad-activate, but that's just a nit.

 Now just (accidental) additions which use yes-or-no-p 
 into kill-emacs-hook are not noticed in emacs 23.1  23.2.
 
 
 Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] Output unmodified Content-Type header value for JSON format.

[Pieter Praet]

On Tue, 22 Nov 2011 22:40:21 -0500, Austin Clements amdra...@mit.edu wrote:
 Quoth Jameson Graef Rollins on Nov 20 at 12:10 pm:
  The open question seems to be how we handle the content encoding
  parameters.  My argument is that those should either be used by notmuch
  to properly encode the content for the consumer.  If that's not
  possible, then just those parameters needed by the consumer to decode
  the content should be output.
 
 If notmuch is going to include part content in the JSON output (which
 perhaps it shouldn't, as per recent IRC discussions), then it must
 handle content encodings because JSON must be Unicode and therefore
 the content strings in the JSON must be Unicode.

Having missed the IRC discussions: what is the rationale for not
including (specific types of?) part content in the JSON output ?
Eg. how about inline attached text/x-patch ?

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


Peace

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

Re: [PATCH] cli: factor out config handling code to get/set lists.

[Pieter Praet]

On Mon, 12 Dec 2011 14:26:21 -0400, David Bremner da...@tethera.net wrote:
 On Sun, 11 Dec 2011 20:41:53 +0400, Dmitry Kurochkin 
 dmitry.kuroch...@gmail.com wrote:
  Hi David.
  
  On Sun, 11 Dec 2011 12:07:51 -0400, David Bremner da...@tethera.net wrote:
   From: David Bremner brem...@debian.org
   
   Two new internal routines are created _config_get_list and
   _config_set_list; the notmuch_config_get_* functions that deal with
   lists are simply wrappers for these functions.
 
 Updated version pushed. I'm not completely happy with _config_get_list's
 weird API, but I don't have a better idea now.
 
 d
 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch

Much cleaner!

However... this would preferrably have been preceded by tests.

Patch follows.


Peace

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

Re: [PATCH] Output unmodified Content-Type header value for JSON format.

[Austin Clements]

Quoth Pieter Praet on Jan 12 at  6:07 pm:
 On Tue, 22 Nov 2011 22:40:21 -0500, Austin Clements amdra...@mit.edu wrote:
  Quoth Jameson Graef Rollins on Nov 20 at 12:10 pm:
   The open question seems to be how we handle the content encoding
   parameters.  My argument is that those should either be used by notmuch
   to properly encode the content for the consumer.  If that's not
   possible, then just those parameters needed by the consumer to decode
   the content should be output.
  
  If notmuch is going to include part content in the JSON output (which
  perhaps it shouldn't, as per recent IRC discussions), then it must
  handle content encodings because JSON must be Unicode and therefore
  the content strings in the JSON must be Unicode.
 
 Having missed the IRC discussions: what is the rationale for not
 including (specific types of?) part content in the JSON output ?
 Eg. how about inline attached text/x-patch ?

Technically the IRC discussion was about not including *any* part
content in the JSON output, and always using show --format=raw or
similar to retrieve desired parts.  Currently, notmuch includes part
content in the JSON only for text/*, *except* when it's text/html.  I
assume non-text parts are omitted because binary data is hard to
represent in JSON and text/html is omitted because some people don't
need it.  However, this leads to some peculiar asymmetry in the Emacs
code where sometimes it pulls part content out of the JSON and
sometimes it retrieves it using show --format=raw.  This in turn leads
to asymmetry in content encoding handling, since notmuch handles
content encoding for parts included in the JSON (and there's no good
way around that since JSON is Unicode), but not for parts retrieved as
raw.

The idea discussed on IRC was to remove all part content from the JSON
output and to always use show to retrieve it, possibly beefing up
show's support for content decoding (and possibly introducing a way to
retrieve multiple raw parts at once to avoid re-parsing).  This would
get the JSON format out of the business of guessing what consumers
need, simplify the Emacs code, and normalize content encoding
handling.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] test: cli: getting/setting/removing config values

[Pieter Praet]

Should have come before commit 1df71b55

---
 test/config   |   88 +
 test/notmuch-test |1 +
 2 files changed, 89 insertions(+), 0 deletions(-)
 create mode 100755 test/config

diff --git a/test/config b/test/config
new file mode 100755
index 000..ee3126c
--- /dev/null
+++ b/test/config
@@ -0,0 +1,88 @@
+#!/usr/bin/env bash
+test_description='notmuch config'
+. ./test-lib.sh
+
+
+config_options=(
+database.path
+user.name
+user.primary_email
+user.other_email
+new.tags
+maildir.synchronize_flags
+)
+
+
+test_begin_subtest 'getting config: config get section.item'
+echo -n   OUTPUT
+for i in ${config_options[*]} ; do
+notmuch config get ${i}
+done  OUTPUT
+cat EXPECTED EOF
+${MAIL_DIR}
+Notmuch Test Suite
+test_su...@notmuchmail.org
+test_suite_ot...@notmuchmail.org
+test_su...@otherdomain.org
+unread
+inbox
+true
+EOF
+test_expect_equal_file OUTPUT EXPECTED
+
+
+test_begin_subtest 'setting config: config set section.item [values ...]'
+notmuch config set database.path /path/to/maildir
+notmuch config set user.name User Name
+notmuch config set user.primary_email primary_em...@notmuchmail.org
+notmuch config set user.other_email a...@notmuchmail.org a...@notmuchmail.org
+notmuch config set new.tags tag1 tag2 tag3
+notmuch config set maildir.synchronize_flags false
+echo -n   OUTPUT
+for i in ${config_options[*]} ; do
+notmuch config get ${i}
+done  OUTPUT
+cat EXPECTED EOF
+/path/to/maildir
+User Name
+primary_em...@notmuchmail.org
+a...@notmuchmail.org
+a...@notmuchmail.org
+tag1
+tag2
+tag3
+false
+EOF
+test_expect_equal_file OUTPUT EXPECTED
+
+
+test_begin_subtest 'removing config: config set section.item'
+notmuch config set database.path
+notmuch config set user.name
+notmuch config set user.primary_email
+notmuch config set user.other_email
+notmuch config set new.tags
+notmuch config set maildir.synchronize_flags
+echo -n   OUTPUT
+for i in ${config_options[*]} ; do
+notmuch config get ${i}
+done  OUTPUT
+
+# FIXME: Not the most robust nor portable solution here...
+# Especially `hostname --domain' may have unwanted effects on
+# some platforms, e.g. setting your hostname to --domain ;)
+fallback_name=$(grep $(id -un) /etc/passwd | cut -d : -f 5 | cut -d , -f 
1)
+fallback_email=$(id -un)@$(hostname).$(hostname --domain)
+
+cat EXPECTED EOF
+${HOME}/mail
+${fallback_name}
+${fallback_email}
+unread
+inbox
+true
+EOF
+test_expect_equal_file OUTPUT EXPECTED
+
+
+test_done
diff --git a/test/notmuch-test b/test/notmuch-test
index e40ef86..f0c1d7c 100755
--- a/test/notmuch-test
+++ b/test/notmuch-test
@@ -18,6 +18,7 @@ cd $(dirname $0)
 
 TESTS=
   basic
+  config
   help-test
   new
   count
-- 
1.7.8.1

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

Re: [PATCH v3] emacs: support notmuch new as a notmuch-poll-script

[Pieter Praet]

On Mon, 12 Dec 2011 22:50:04 +0200, Jani Nikula j...@nikula.org wrote:
 Support nil value for notmuch-poll-script to run notmuch new instead of
 an external script, and make this the new default. notmuch new is run
 using the configured notmuch-command.
 
 This allows taking better advantage of the notmuch new hooks from emacs
 without intermediate scripts.
 
 Signed-off-by: Jani Nikula j...@nikula.org
 
 ---
 
 v3: only documentation changes suggested by Austin and Dmitry.
 ---
  emacs/notmuch.el |   35 +--
  1 files changed, 25 insertions(+), 10 deletions(-)
 
 diff --git a/emacs/notmuch.el b/emacs/notmuch.el
 index 8936149..675a110 100644
 --- a/emacs/notmuch.el
 +++ b/emacs/notmuch.el
 @@ -965,28 +965,43 @@ same relative position within the new buffer.
  (notmuch-search query oldest-first target-thread target-line 
 continuation)
  (goto-char (point-min
  
 -(defcustom notmuch-poll-script 
 +(defcustom notmuch-poll-script nil
An external script to incorporate new mail into the notmuch database.
  
 -If this variable is non empty, then it should name a script to be
 -invoked by `notmuch-search-poll-and-refresh-view' and
 +This variable controls the action invoked by
 +`notmuch-search-poll-and-refresh-view' and
  `notmuch-hello-poll-and-update' (each have a default keybinding
 -of 'G'). The script could do any of the following depending on
 +of 'G') to incorporate new mail into the notmuch database.
 +
 +If set to nil (the default), new mail is processed by invoking
 +\notmuch new\. Otherwise, this should be set to a string that
 +gives the name of an external script that processes new mail. If
 +set to the empty string, no command will be run.
 +
 +The external script could do any of the following depending on
  the user's needs:
  
  1. Invoke a program to transfer mail to the local mail store
  2. Invoke \notmuch new\ to incorporate the new mail
 -3. Invoke one or more \notmuch tag\ commands to classify the mail
 -  :type 'string
 +3. Invoke one or more \notmuch tag\ commands to classify the mail
 +
 +Note that the recommended way of achieving the same is using
 +\notmuch new\ hooks.
 +  :type '(choice (const :tag notmuch new nil)
 +  (const :tag Disabled )
 +  (string :tag Custom script))
:group 'notmuch)
  
  (defun notmuch-poll ()
 -  Run external script to import mail.
 +  Run \notmuch new\ or an external script to import mail.
  
 -Invokes `notmuch-poll-script' if it is not set to an empty string.
 +Invokes `notmuch-poll-script', \notmuch new\, or does nothing
 +depending on the value of `notmuch-poll-script'.
(interactive)
 -  (if (not (string= notmuch-poll-script ))
 -  (call-process notmuch-poll-script nil nil)))
 +  (if (stringp notmuch-poll-script)
 +  (if (not (string= notmuch-poll-script ))
 +   (call-process notmuch-poll-script nil nil))
 +(call-process notmuch-command nil nil nil new)))

Since it seems to be bikeshedding-season:

When `(if (not's don't have an `else'-part, use `unless' instead ?

Patch follows.

  
  (defun notmuch-search-poll-and-refresh-view ()
Invoke `notmuch-poll' to import mail, then refresh the current view.
 -- 
 1.7.5.4
 
 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch


Nicely complements the new hooks (for which thanks) !


Peace

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

[PATCH] emacs: globally replace non-branching (if (not ... with (unless ...

[Pieter Praet]

Less code, same results, without sacrificing readability.

---
 emacs/notmuch-address.el |6 +++---
 emacs/notmuch-hello.el   |   20 ++--
 emacs/notmuch-show.el|   12 ++--
 emacs/notmuch.el |8 
 4 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/emacs/notmuch-address.el b/emacs/notmuch-address.el
index 8eba7a0..d72b169 100644
--- a/emacs/notmuch-address.el
+++ b/emacs/notmuch-address.el
@@ -37,9 +37,9 @@ line.
 (defvar notmuch-address-history nil)
 
 (defun notmuch-address-message-insinuate ()
-  (if (not (memq notmuch-address-message-alist-member 
message-completion-alist))
-  (setq message-completion-alist
-   (push notmuch-address-message-alist-member 
message-completion-alist
+  (unless (memq notmuch-address-message-alist-member message-completion-alist)
+(setq message-completion-alist
+ (push notmuch-address-message-alist-member 
message-completion-alist
 
 (defun notmuch-address-options (original)
   (process-lines notmuch-address-command original))
diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index 333d4c1..dce2020 100644
--- a/emacs/notmuch-hello.el
+++ b/emacs/notmuch-hello.el
@@ -315,7 +315,7 @@ should be. Returns a cons cell `(tags-per-line width)'.
 
 ;; If the last line was not full (and hence did not include a
 ;; carriage return), insert one now.
-(if (not (eq (% count tags-per-line) 0))
+(unless (eq (% count tags-per-line) 0)
(widget-insert \n))
 found-target-pos))
 
@@ -399,7 +399,7 @@ Complete list of currently available key bindings:
 
   ; Jump through a hoop to get this value from the deprecated variable
   ; name (`notmuch-folders') or from the default value.
-  (if (not notmuch-saved-searches)
+  (unless notmuch-saved-searches
 (setq notmuch-saved-searches (notmuch-saved-searches)))
 
   (if no-display
@@ -565,18 +565,18 @@ Complete list of currently available key bindings:
  (widget-insert \n\n)
  (let ((start (point)))
(setq found-target-pos (notmuch-hello-insert-tags alltags-alist 
widest target))
-   (if (not final-target-pos)
-   (setq final-target-pos found-target-pos))
+   (unless final-target-pos
+ (setq final-target-pos found-target-pos))
(indent-rigidly start (point) notmuch-hello-indent)))
 
(widget-insert \n)
 
-   (if (not notmuch-show-all-tags-list)
-   (widget-create 'push-button
-  :notify (lambda (widget rest ignore)
-(setq notmuch-show-all-tags-list t)
-(notmuch-hello-update))
-  Show all tags)))
+   (unless notmuch-show-all-tags-list
+ (widget-create 'push-button
+:notify (lambda (widget rest ignore)
+  (setq notmuch-show-all-tags-list t)
+  (notmuch-hello-update))
+Show all tags)))
 
   (let ((start (point)))
(widget-insert \n\n)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 5502efd..d3543f0 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -659,8 +659,8 @@ current buffer, if possible.
   ;; part, so we make sure that we're down at the end.
   (goto-char (point-max))
   ;; Ensure that the part ends with a carriage return.
-  (if (not (bolp))
-  (insert \n)))
+  (unless (bolp)
+(insert \n)))
 
 (defun notmuch-show-insert-body (msg body depth)
   Insert the body BODY at depth DEPTH in the current thread.
@@ -740,8 +740,8 @@ current buffer, if possible.
 (setq body-start (point-marker))
 (notmuch-show-insert-body msg (plist-get msg :body) depth)
 ;; Ensure that the body ends with a newline.
-(if (not (bolp))
-   (insert \n))
+(unless (bolp)
+  (insert \n))
 (setq body-end (point-marker))
 (setq content-end (point-marker))
 
@@ -882,8 +882,8 @@ buffer.
   (run-hooks 'notmuch-show-hook))
 
 ;; Move straight to the first open message
-(if (not (notmuch-show-message-visible-p))
-   (notmuch-show-next-open-message))
+(unless (notmuch-show-message-visible-p)
+  (notmuch-show-next-open-message))
 
 ;; Set the header line to the subject of the first open message.
 (setq header-line-format (notmuch-show-strip-re 
(notmuch-show-get-subject)))
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 1e61775..ba84494 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -636,8 +636,8 @@ This function advances the next thread when finished.
(if notmuch-search-process-filter-data
(insert (concat Error: Unexpected output from 
notmuch search:\n notmuch-search-process-filter-data)))
(insert End of search results.)
-   (if (not (= exit-status 0))
-   (insert 

Re: [PATCH] test: don't bail out of `run_emacs' too early when missing prereqs

[Dmitry Kurochkin]

On Thu, 12 Jan 2012 18:16:59 +0100, Pieter Praet pie...@praet.org wrote:
 When running the Emacs tests in verbose mode, only the first missing
 prereq is reported because the `run_emacs' function is short-circuited
 early:
 
   #+begin_example
 emacs: Testing emacs interface
  missing prerequisites: [0]  emacs(1)
  skipping test: [0]  Basic notmuch-hello view in emacs
  SKIP   [0]  Basic notmuch-hello view in emacs
   #+end_example
 
 This can lead to situations reminiscent of dependency hell, so instead
 of returning based on each individual `test_require_external_prereq's exit
 status, we now do so by checking $test_subtest_missing_external_prereqs_:
 
   #+begin_example
 emacs: Testing emacs interface
  missing prerequisites: [0]  dtach(1) emacs(1) emacsclient(1)
  skipping test: [0]  Basic notmuch-hello view in emacs
  SKIP   [0]  Basic notmuch-hello view in emacs
   #+end_example
 
 Also add missing prereq for dtach(1).
 
 ---
  test/test-lib.sh |6 --
  1 files changed, 4 insertions(+), 2 deletions(-)
 
 diff --git a/test/test-lib.sh b/test/test-lib.sh
 index 82767c0..6ec3882 100644
 --- a/test/test-lib.sh
 +++ b/test/test-lib.sh
 @@ -907,8 +907,10 @@ EOF
  
  test_emacs () {
   # test dependencies beforehand to avoid the waiting loop below
 - test_require_external_prereq emacs || return
 - test_require_external_prereq emacsclient || return
 + test_require_external_prereq dtach
 + test_require_external_prereq emacs
 + test_require_external_prereq emacsclient
 + test -z $test_subtest_missing_external_prereqs_ || return

There may be other missing dependencies before test_emacs() is called
and $test_subtest_missing_external_prereqs_ would not be blank.  Also, I
would like to keep the number of functions that use
$test_subtest_missing_external_prereqs_ minimal.  How about:

  missing_dependencies=
  test_require_... dtach || missing_dependencies=1
  test_require_... emacs || missing_dependencies=1
  ...
  test -z $missing_dependencies || return

Regards,
  Dmitry

  
   if [ -z $EMACS_SERVER ]; then
   server_name=notmuch-test-suite-$$
 -- 
 1.7.8.1
 
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] emacs: globally replace non-branching (if (not ... with (unless ...

[Dmitry Kurochkin]

On Thu, 12 Jan 2012 18:33:06 +0100, Pieter Praet pie...@praet.org wrote:
 Less code, same results, without sacrificing readability.
 

+1

Regards,
  Dmitry

 ---
  emacs/notmuch-address.el |6 +++---
  emacs/notmuch-hello.el   |   20 ++--
  emacs/notmuch-show.el|   12 ++--
  emacs/notmuch.el |8 
  4 files changed, 23 insertions(+), 23 deletions(-)
 
 diff --git a/emacs/notmuch-address.el b/emacs/notmuch-address.el
 index 8eba7a0..d72b169 100644
 --- a/emacs/notmuch-address.el
 +++ b/emacs/notmuch-address.el
 @@ -37,9 +37,9 @@ line.
  (defvar notmuch-address-history nil)
  
  (defun notmuch-address-message-insinuate ()
 -  (if (not (memq notmuch-address-message-alist-member 
 message-completion-alist))
 -  (setq message-completion-alist
 - (push notmuch-address-message-alist-member 
 message-completion-alist
 +  (unless (memq notmuch-address-message-alist-member 
 message-completion-alist)
 +(setq message-completion-alist
 +   (push notmuch-address-message-alist-member 
 message-completion-alist
  
  (defun notmuch-address-options (original)
(process-lines notmuch-address-command original))
 diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
 index 333d4c1..dce2020 100644
 --- a/emacs/notmuch-hello.el
 +++ b/emacs/notmuch-hello.el
 @@ -315,7 +315,7 @@ should be. Returns a cons cell `(tags-per-line width)'.
  
  ;; If the last line was not full (and hence did not include a
  ;; carriage return), insert one now.
 -(if (not (eq (% count tags-per-line) 0))
 +(unless (eq (% count tags-per-line) 0)
   (widget-insert \n))
  found-target-pos))
  
 @@ -399,7 +399,7 @@ Complete list of currently available key bindings:
  
; Jump through a hoop to get this value from the deprecated variable
; name (`notmuch-folders') or from the default value.
 -  (if (not notmuch-saved-searches)
 +  (unless notmuch-saved-searches
  (setq notmuch-saved-searches (notmuch-saved-searches)))
  
(if no-display
 @@ -565,18 +565,18 @@ Complete list of currently available key bindings:
 (widget-insert \n\n)
 (let ((start (point)))
   (setq found-target-pos (notmuch-hello-insert-tags alltags-alist 
 widest target))
 - (if (not final-target-pos)
 - (setq final-target-pos found-target-pos))
 + (unless final-target-pos
 +   (setq final-target-pos found-target-pos))
   (indent-rigidly start (point) notmuch-hello-indent)))
  
   (widget-insert \n)
  
 - (if (not notmuch-show-all-tags-list)
 - (widget-create 'push-button
 -:notify (lambda (widget rest ignore)
 -  (setq notmuch-show-all-tags-list t)
 -  (notmuch-hello-update))
 -Show all tags)))
 + (unless notmuch-show-all-tags-list
 +   (widget-create 'push-button
 +  :notify (lambda (widget rest ignore)
 +(setq notmuch-show-all-tags-list t)
 +(notmuch-hello-update))
 +  Show all tags)))
  
(let ((start (point)))
   (widget-insert \n\n)
 diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
 index 5502efd..d3543f0 100644
 --- a/emacs/notmuch-show.el
 +++ b/emacs/notmuch-show.el
 @@ -659,8 +659,8 @@ current buffer, if possible.
;; part, so we make sure that we're down at the end.
(goto-char (point-max))
;; Ensure that the part ends with a carriage return.
 -  (if (not (bolp))
 -  (insert \n)))
 +  (unless (bolp)
 +(insert \n)))
  
  (defun notmuch-show-insert-body (msg body depth)
Insert the body BODY at depth DEPTH in the current thread.
 @@ -740,8 +740,8 @@ current buffer, if possible.
  (setq body-start (point-marker))
  (notmuch-show-insert-body msg (plist-get msg :body) depth)
  ;; Ensure that the body ends with a newline.
 -(if (not (bolp))
 - (insert \n))
 +(unless (bolp)
 +  (insert \n))
  (setq body-end (point-marker))
  (setq content-end (point-marker))
  
 @@ -882,8 +882,8 @@ buffer.
(run-hooks 'notmuch-show-hook))
  
  ;; Move straight to the first open message
 -(if (not (notmuch-show-message-visible-p))
 - (notmuch-show-next-open-message))
 +(unless (notmuch-show-message-visible-p)
 +  (notmuch-show-next-open-message))
  
  ;; Set the header line to the subject of the first open message.
  (setq header-line-format (notmuch-show-strip-re 
 (notmuch-show-get-subject)))
 diff --git a/emacs/notmuch.el b/emacs/notmuch.el
 index 1e61775..ba84494 100644
 --- a/emacs/notmuch.el
 +++ b/emacs/notmuch.el
 @@ -636,8 +636,8 @@ This function advances the next thread when finished.
   (if notmuch-search-process-filter-data
   (insert (concat Error: Unexpected output from 
 notmuch search:\n 

Re: Emacs: Crypto: How to get automatic encryption?

[Jameson Graef Rollins]

On Tue, 03 Jan 2012 13:45:14 -0800, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 Unfortunately, auto encrypting of replies to encrypted emails is not yet
 implemented.  It is desperately needed, though, obviously.  So this is a
 good excuse to start a discussion about how we could achieve this.
 
 It just occurs to me that a way to do this would be to have notmuch
 reply add the appropriate mml #secure tag for encryption to the output
 reply template, maybe with something like a --emacs option.  That would
 be pretty easy to implement, although it would obviously be very UI
 specific.
 
 Another possibility would be for notmuch reply to add some sort of
 header to the reply message to indicate that the original was encrypted,
 and then do something in emacs to try to read that header and add the
 appropriate mml #secure tag.  That would also be easy to implement in
 the notmuch CLI, and it would be more UI agnostic, but it would require
 a lot more elisp.

There is a set of patches in the queue to add a JSON output format for
reply, with the emacs UI then consuming that to construct the reply
template [0].  This will make it very easy to communicate to the emacs
UI that the original message was encrypted, and that the reply should be
similarly encrypted.  I'm going to wait until that patch set makes it
through, and then build this functionality on top of that.

jamie.

[0] id:1326009162-19524-3-git-send-email-awg+notm...@xvx.ca


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

Re: [PATCH v2] notmuch/emacs: Observe the charset of text/html parts, where known.

[Austin Clements]

Quoth David Edmondson on Jan 12 at  1:31 pm:
 Add the charset of text/html parts to the JSON output of 'notmuch
 -show' when it is known. Observe the encoding when rendering such
 parts in emacs.

This seems like a fine interim solution to me, though I'd like to see
a comment above the change in format_part_content_json explaining why
we include the content charset for text/html and not for anything
else.  Perhaps something like,

/* For non-HTML text/* parts, we include the content in the JSON.
 * Since JSON must be Unicode, we handle charset decoding here and do
 * not report a charset to the caller.  For text/html parts, we do not
 * include the content.  If a caller is interested in text/html parts,
 * it should retrieve them separately.  Since this makes charset
 * decoding the responsibility on the caller, we report the charset
 * for text/html parts. */
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: Emacs: Crypto: How to get automatic encryption?

[Gregor Zattler]

Hi Jameson,
* Jameson Graef Rollins jroll...@finestructure.net [12. Jan. 2012]:
 On Tue, 03 Jan 2012 13:45:14 -0800, Jameson Graef Rollins 
 jroll...@finestructure.net wrote:
 Unfortunately, auto encrypting of replies to encrypted emails is not yet
 implemented.  It is desperately needed, though, obviously.  So this is a
 good excuse to start a discussion about how we could achieve this.
[...]
 There is a set of patches in the queue to add a JSON output format for
 reply, with the emacs UI then consuming that to construct the reply
 template [0].  This will make it very easy to communicate to the emacs
 UI that the original message was encrypted, and that the reply should be
 similarly encrypted.  I'm going to wait until that patch set makes it
 through, and then build this functionality on top of that.
 [0] id:1326009162-19524-3-git-send-email-awg+notm...@xvx.ca


That would be really great.

But how about not only replying encrypted but encrypting every
email if possible?  Possible could mean different things,
though:

1) encrypt if fully trusted suitable public keys for all
   recipients are GnuPG key ring.

2) encrypt if suitable public keys for all recipients are in
   GnuPGs key ring.

3) try to fetch suitable public keys from server in order to to
   check 2).


I for instance fiddled with my mutt configuration to achieve 1).

But I have no clue about how to do this with notmuch/Emacs.

Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH v2] notmuch/emacs: Observe the charset of text/html parts, where known.

[David Edmondson]

On Thu, 12 Jan 2012 13:49:59 -0500, Austin Clements amdra...@mit.edu wrote:
 Quoth David Edmondson on Jan 12 at  1:31 pm:
  Add the charset of text/html parts to the JSON output of 'notmuch
  -show' when it is known. Observe the encoding when rendering such
  parts in emacs.
 
 This seems like a fine interim solution to me, though I'd like to see
 a comment above the change in format_part_content_json explaining why
 we include the content charset for text/html and not for anything
 else.

Okay, thanks. New patch tomorrow.


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

Re: Emacs: Crypto: How to get automatic encryption?

[Jameson Graef Rollins]

On Thu, 12 Jan 2012 20:05:14 +0100, Gregor Zattler telegr...@gmx.net wrote:
 But how about not only replying encrypted but encrypting every
 email if possible?  Possible could mean different things,
 though:

This is already easy to do in emacs, and doesn't require any special
notmuch support:

(add-hook 'message-setup-hook mml-secure-message-encrypt-pgpmime)

This is the same as what I suggested for auto-sign.  You might have to
do a little elisp hacking to do fancier stuff, but again, doing
something for all outgoing mail is more about message-mode, and is not
notmuch specific.

jamie.


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

Re: Emacs: Crypto: How to get automatic encryption?

[Darren McGuicken]

On Thu, 12 Jan 2012 20:05:14 +0100, Gregor Zattler telegr...@gmx.net wrote:
 2) encrypt if suitable public keys for all recipients are in
GnuPGs key ring.
[...]
 But I have no clue about how to do this with notmuch/Emacs.

Isn't that what David provides an elisp-snippet for in
id:cunk4576ezs@hotblack-desiato.hh.sledj.net?

I've been using it myself since it was posted and it seems to work
according to the behaviour you desire in point 2.


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

[PATCH v4 0/5] reply to sender

[Jani Nikula]

Hi all, changes since v3:

Split the first patch into two, the first one refactoring the reply/from address
scanning, and the second one adding the actual reply-to-sender feature. This
addresses Austins comments in id:20120112033146.gu20...@mit.edu (and does
improve the code).

Patches 3-5 remain unchanged.


BR,
Jani.


Jani Nikula (4):
  cli: slightly refactor notmuch reply address scanning functions
  cli: add support for replying just to the sender in notmuch reply
  emacs: add support for replying just to the sender
  emacs: bind 'r' to reply-to-sender and 'R' to reply-to-all

Mark Walters (1):
  test: add tests for notmuch reply --reply-to=sender

 emacs/notmuch-mua.el |9 ++-
 emacs/notmuch-show.el|   12 ++-
 emacs/notmuch.el |   11 ++-
 man/man1/notmuch-reply.1 |   28 +-
 notmuch-reply.c  |  122 +--
 test/notmuch-test|1 +
 test/reply-to-sender |  209 ++
 7 files changed, 335 insertions(+), 57 deletions(-)
 create mode 100755 test/reply-to-sender

-- 
1.7.5.4

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

[PATCH v4 1/5] cli: slightly refactor notmuch reply address scanning functions

[Jani Nikula]

Slightly refactor notmuch reply recipient and user from address scanning
functions in preparation for reply-to-sender feature.

Add support for not adding messages at all (just scan for user from
address), and returning the number of messages added.

No externally visible functional changes.

Signed-off-by: Jani Nikula j...@nikula.org
---
 notmuch-reply.c |   74 --
 1 files changed, 38 insertions(+), 36 deletions(-)

diff --git a/notmuch-reply.c b/notmuch-reply.c
index 000f6da..4fae66f 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -168,22 +168,28 @@ address_is_users (const char *address, notmuch_config_t 
*config)
 return 0;
 }
 
-/* For each address in 'list' that is not configured as one of the
- * user's addresses in 'config', add that address to 'message' as an
- * address of 'type'.
+/* Scan addresses in 'list'.
  *
- * The first address encountered that *is* the user's address will be
- * returned, (otherwise NULL is returned).
+ * If 'message' is non-NULL, then for each address in 'list' that is not
+ * configured as one of the user's addresses in 'config', add that address to
+ * 'message' as an address of 'type'.
+ *
+ * If 'user_from' is non-NULL and *user_from is NULL, the first address
+ * encountered in 'list' that *is* the user's address will be set to 
*user_from.
+ *
+ * Return the number of addresses added to 'message'. (If 'message' is NULL, 
the
+ * function returns 0 by definition.)
  */
-static const char *
-add_recipients_for_address_list (GMimeMessage *message,
-notmuch_config_t *config,
-GMimeRecipientType type,
-InternetAddressList *list)
+static unsigned int
+scan_address_list (InternetAddressList *list,
+  notmuch_config_t *config,
+  GMimeMessage *message,
+  GMimeRecipientType type,
+  const char **user_from)
 {
 InternetAddress *address;
 int i;
-const char *ret = NULL;
+unsigned int n = 0;
 
 for (i = 0; i  internet_address_list_length (list); i++) {
address = internet_address_list_get_address (list, i);
@@ -196,8 +202,7 @@ add_recipients_for_address_list (GMimeMessage *message,
if (group_list == NULL)
continue;
 
-   add_recipients_for_address_list (message, config,
-type, group_list);
+   n += scan_address_list (group_list, config, message, type, NULL);
} else {
InternetAddressMailbox *mailbox;
const char *name;
@@ -209,40 +214,40 @@ add_recipients_for_address_list (GMimeMessage *message,
addr = internet_address_mailbox_get_addr (mailbox);
 
if (address_is_users (addr, config)) {
-   if (ret == NULL)
-   ret = addr;
-   } else {
+   if (user_from  *user_from == NULL)
+   *user_from = addr;
+   } else if (message) {
g_mime_message_add_recipient (message, type, name, addr);
+   n++;
}
}
 }
 
-return ret;
+return n;
 }
 
-/* For each address in 'recipients' that is not configured as one of
- * the user's addresses in 'config', add that address to 'message' as
- * an address of 'type'.
+/* Scan addresses in 'recipients'.
  *
- * The first address encountered that *is* the user's address will be
- * returned, (otherwise NULL is returned).
+ * See the documentation of scan_address_list() above. This function does
+ * exactly the same, but converts 'recipients' to an InternetAddressList first.
  */
-static const char *
-add_recipients_for_string (GMimeMessage *message,
-  notmuch_config_t *config,
-  GMimeRecipientType type,
-  const char *recipients)
+static unsigned int
+scan_address_string (const char *recipients,
+notmuch_config_t *config,
+GMimeMessage *message,
+GMimeRecipientType type,
+const char **user_from)
 {
 InternetAddressList *list;
 
 if (recipients == NULL)
-   return NULL;
+   return 0;
 
 list = internet_address_list_parse_string (recipients);
 if (list == NULL)
-   return NULL;
+   return 0;
 
-return add_recipients_for_address_list (message, config, type, list);
+return scan_address_list (list, config, message, type, user_from);
 }
 
 /* Does the address in the Reply-To header of 'message' already appear
@@ -324,7 +329,7 @@ add_recipients_from_message (GMimeMessage *reply,
 }
 
 for (i = 0; i  ARRAY_SIZE (reply_to_map); i++) {
-   const char *addr, *recipients;
+   const char *recipients;
 
recipients = notmuch_message_get_header (message,
 reply_to_map[i].header);
@@ -332,11 +337,8