[PATCH 2/4] emacs: repurpose notmuch-show-archive-thread-internal function for general thread tagging

2012-01-10 Thread Jameson Graef Rollins
On Wed, 11 Jan 2012 00:53:35 -0500, Aaron Ecay  wrote:
> On Tue, 10 Jan 2012 18:56:29 -0800, Jameson Graef Rollins  finestructure.net> wrote:
> > Actually, the show-next argument was already part of the function.  I
> > did not introduce it.  And it wasn't optional originally, so if we want
> > to change that behavior we should probably do so in a separate patch.
> 
> Hrm.  I didn?t communicate as clearly as I could have ? you are correct
> that the show-next argument to the notmuch-show-archive-internal function
> was pre-existing.  But notmuch-show-tag-thread-internal is a new function,
> with potentially expanded usefulness to third-party code.  Thus I think
> I?m in the clear to bikeshed about its calling convention.  :) It?s your
> patch, though, so it?s your call if you feel that the  goes best
> in a new change.

No, I see your point, Aaron.  I'll rework it to make it a little clean
and more flexible when I resend.  Thanks again.

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/20120110/57bde9d1/attachment.pgp>


[PATCH 0/3] Automatic tag-based exclusion

2012-01-10 Thread Jameson Graef Rollins
On Wed, 11 Jan 2012 00:02:50 -0500, Austin Clements  wrote:
> This implements essentially the same idea as Jamie's patch, but does
> it in the library/CLI and operates on the parsed query rather than
> using an ad hoc regexp.  Which tags are automatically excluded is set
> in the config file and defaults to "deleted" and "spam".

Yay Austin!  Nice fast work!  That's really great.  Don't have time to
review right now, but asap.

I'll resend my emacs patches as soon as I can as well.

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/20120110/79554dd1/attachment.pgp>


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

2012-01-10 Thread Jani Nikula
On Tue, 10 Jan 2012 22:41:49 +0200, Jani Nikula  wrote:
> On Tue, 10 Jan 2012 16:18:21 +, David Edmondson  wrote:
> > I have a vague recollection that someone reported a bug where
> > `(window-width)' was not the right value to use if `line-number-mode' is
> > enabled, but I can't find it again now. (Someone should build an email
> > client that allows easy searching.)
> 
> Do you perhaps mean this: id:"87k47nlpzb.fsf at nausicaa.localdomain"

[Now also to the list. Got bitten by my own patch binding 'r' to
reply-to-sender. Perhaps it's really too drastic to change that now...]


[PATCH v2] emacs: Cycle through notmuch buffers rather than jumping to the last.

2012-01-10 Thread Jani Nikula
On Tue, 10 Jan 2012 16:55:07 +, David Edmondson  wrote:
> On Wed, 28 Dec 2011 08:29:58 +, David Edmondson  wrote:
> > As suggested by j4ni in #notmuch, rename
> > `notmuch-jump-to-recent-buffer' as `notmuch-cycle-notmuch-buffers' and
> > have it behave accordingly.
> > 
> > Consider `message-mode' buffers to be of interest.
> 
> Any reviewers?

I don't feel qualified to review, but the patch works for me.

BR,
Jani.


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

2012-01-10 Thread Jani Nikula
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.
> 
> Hence, avoid padding the last column on each row.
> ---
> 
> Thanks to j4ni in #notmuch for spotting this.

Thanks for fixing this. This patch works for me.

BR,
j4ni.


> 
>  emacs/notmuch-hello.el |   20 +++-
>  1 files changed, 11 insertions(+), 9 deletions(-)
> 
> diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
> index 333d4c1..02017ce 100644
> --- a/emacs/notmuch-hello.el
> +++ b/emacs/notmuch-hello.el
> @@ -299,15 +299,17 @@ should be. Returns a cons cell `(tags-per-line width)'."
>  :notify #'notmuch-hello-widget-search
>  :notmuch-search-terms query
>  formatted-name)
> - ;; Insert enough space to consume the rest of the
> - ;; column.  Because the button for the name is `(1+
> - ;; (length name))' long (due to the trailing space) we
> - ;; can just insert `(- widest (length name))' spaces -
> - ;; the column separator is included in the button if
> - ;; `(equal widest (length name)'.
> - (widget-insert (make-string (max 1
> -  (- widest (length name)))
> - ? 
> + (unless (eq (% count tags-per-line) (1- tags-per-line))
> +   ;; If this is not the last tag on the line, insert
> +   ;; enough space to consume the rest of the column.
> +   ;; Because the button for the name is `(1+ (length
> +   ;; name))' long (due to the trailing space) we can
> +   ;; just insert `(- widest (length name))' spaces - the
> +   ;; column separator is included in the button if
> +   ;; `(equal widest (length name)'.
> +   (widget-insert (make-string (max 1
> +(- widest (length name)))
> +   ? )
>   (setq count (1+ count))
>   (if (eq (% count tags-per-line) 0)
>   (widget-insert "\n")))
> -- 
> 1.7.7.3
> 
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch


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

2012-01-10 Thread 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 v3 3/4] emacs: bind 'r' to reply-to-sender and 'R' to reply-to-all

2012-01-10 Thread 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 v3 2/4] emacs: add support for replying just to the sender

2012-01-10 Thread 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 v3 1/4] cli: add support for replying just to the sender in "notmuch reply"

2012-01-10 Thread 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  |   70 ++---
 2 files changed, 76 insertions(+), 22 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 000f6da..7b785a7 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -170,7 +170,7 @@ address_is_users (const char *address, notmuch_config_t 
*config)

 /* 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'.
+ * address of 'type', if 'add' is true.
  *
  * The first address encountered that *is* the user's address will be
  * returned, (otherwise NULL is returned).
@@ -179,7 +179,8 @@ static const char *
 add_recipients_for_address_list (GMimeMessage *message,
 notmuch_config_t *config,
 GMimeRecipientType type,
-InternetAddressList *list)
+InternetAddressList *list,
+notmuch_bool_t add)
 {
 InternetAddress *address;
 int i;
@@ -197,7 +198,7 @@ add_recipients_for_address_list (GMimeMessage *message,
continue;

add_recipients_for_address_list (message, config,
-type, group_list);
+type, group_list, add);
} else {
InternetAddressMailbox *mailbox;
const char *name;
@@ -211,7 +212,7 @@ add_recipients_for_address_list (GMimeMessage *message,
if (address_is_users (addr, config)) {
if (ret == NULL)
ret = addr;
-   } else {
+   } else if (add) {
g_mime_message_add_recipient (message, type, name, addr);
}
}
@@ -222,7 +223,7 @@ add_recipients_for_address_list (GMimeMessage *message,

 /* 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'.
+ * an address of 'type', if 'add' is true.
  *
  * The first address encountered that *is* the user's address will be
  * returned, (otherwise NULL is returned).
@@ -231,7 +232,8 @@ static const char *
 add_recipients_for_string (GMimeMessage *message,
   notmuch_config_t *config,
   GMimeRecipientType type,
-  const char *recipients)
+  const char *recipients,
+  notmuch_bool_t add)
 {
 InternetAddressList *list;

@@ -242,7 +244,7 @@ 

[PATCH v3 0/4] reply to sender

2012-01-10 Thread Jani Nikula
Hi all, v3 of the reply-to-sender series.

Changes since v2:

- Patches 1 and 2 of the original series were pushed already.

- Patch 1: Don't force recipient type, based on comment by Mark
  (id:"877h11eq3g.fsf at qmul.ac.uk"). Fix man page accordinly, and clean
  up the wording a bit otherwise too.

- Patch 4: Fix according to above change, reverting back to Mark's
  original patch.

There have now been comments for and against patch 3 (rebinding 'r'
for reply-to-sender and 'R' for reply-to-all). Perhaps there are just
too many people that are used to 'r' for reply-to-all by now. I'll
just leave it up to David be the referee here. ;)


BR,
Jani.


Jani Nikula (3):
  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  |   70 
 test/notmuch-test|1 +
 test/reply-to-sender |  209 ++
 7 files changed, 310 insertions(+), 30 deletions(-)
 create mode 100755 test/reply-to-sender

-- 
1.7.5.4



another attempt to add delete functionality in emacs

2012-01-10 Thread Jameson Graef Rollins
On Tue, 10 Jan 2012 16:01:32 -0400, David Bremner  wrote:
> Just thinking out loud here, but it does seem a bit unfortunate to me
> that it represents a pretty fundamental divergence between the CLI and
> the emacs interface. Mind you, I guess one could make the same argument
> about the libs versus the CLI. Lack of configuration information in the
> library (possibly among other reasons) makes this not too nice to
> support in the current library either.

I think a consensus has formed that this functionality (automatically
suppressing messages with certain tags from searches) is better left to
the CLI, rather than implementing it just in the emacs UI.
Unfortunately I'm not going to get to that any time soon.

However, without that functionality, I really see no reason why we
should be adding any built-in support for adding "deleted" tags in the
emacs UI.  Without the CLI change, "deleted" tags aren't handled any
differently than any other tag, so why should the default emacs UI care.
If users want to bind keys to special tagging operations, they can do so
for themselves [0].

In fact, I'm now starting to think we don't need to add any support for
special tagging operations (such as "deleted") even if we *do* have
support for suppressing them in the CLI.  Special tagging operations
should only be supported if the tagged messages are somehow handled
specially.  If not, then again, we should just leave them up to the user
[0].

All that said, I think I'll just resubmit the couple small changes to
the emacs UI that I think we should consider adopting anyway.

jamie.


[0]
(define-key notmuch-show-mode-map "d"
  (lambda ()
"Delete message"
(interactive)
(notmuch-show-add-tag "deleted")
(notmuch-show-next-open-message)))
-- 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/20120110/53d26c97/attachment.pgp>


[PATCH 2/4] emacs: repurpose notmuch-show-archive-thread-internal function for general thread tagging

2012-01-10 Thread Jameson Graef Rollins
On Mon, 09 Jan 2012 00:02:20 -0500, Aaron Ecay  wrote:
> On Sun, 08 Jan 2012 18:49:56 -0800, Jameson Graef Rollins  finestructure.net> wrote:
> > On Sun, 08 Jan 2012 20:08:59 -0500, Aaron Ecay  
> > wrote:
> > >
> > > - It would be good to make show-next   This will enable code
> > >   to call the fn with only two arguments, and not showing next will be
> > >   the default behavior.
> > 
> > That's a nice idea.  Probably better for a separate patch, though.
> 
> This patch introduces show-next as a new argument to the function.  So it
> can and should make it , if that is the appropriate semantics
> for it to have.

Actually, the show-next argument was already part of the function.  I
did not introduce it.  And it wasn't optional originally, so if we want
to change that behavior we should probably do so in a separate patch.

> That said, here?s an alternate proposal: provide two functions as the
> ?external? API, namely ?notmuch-show-{add,remove}-tag-thread? (by
> parallelism with ?notmuch-show-{add,remove}-tag?).  These could be
> thin wrappers around ?notmuch-show-tag-thread-internal?, which would
> then not be intended to be called by user code.

I think that's a better idea.  In the next version I'll add something
like this instead.

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/20120110/f3fc081f/attachment.pgp>


another attempt to add delete functionality in emacs

2012-01-10 Thread Jameson Graef Rollins
On Tue, 10 Jan 2012 07:47:23 +, David Edmondson  wrote:
> I honestly don't understand the reason for this. If someone wants to not
> see messages that they have tagged as 'deleted', they add 'and not
> tag:deleted' to the end of the search expression.

Adding "and not tag:deleted" in all of your searches vs. having it done
automatically?  That a pretty big usability difference to me.

The config variable is included so that people can turn the
functionality on or off as they see fit.

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/20120110/20df6bf6/attachment.pgp>


[PATCH v2] emacs: Cycle through notmuch buffers rather than jumping to the last.

2012-01-10 Thread David Edmondson
On Wed, 28 Dec 2011 08:29:58 +, David Edmondson  wrote:
> As suggested by j4ni in #notmuch, rename
> `notmuch-jump-to-recent-buffer' as `notmuch-cycle-notmuch-buffers' and
> have it behave accordingly.
> 
> Consider `message-mode' buffers to be of interest.

Any reviewers?
-- 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/20120110/4db2bc11/attachment.pgp>


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

2012-01-10 Thread David Edmondson
On Tue, 10 Jan 2012 11:05:02 -0500, Austin Clements  wrote:
> > > Is it possible for a tag in the last column to be just long enough to
> > > make the line still wrap?  Somehow my current tag set doesn't trigger
> > > this bug, so I can't test this case (and I admit I can't follow
> > > notmuch-hello-insert-tags well enough to reason this out).
> > 
> > With a sufficiently narrow window it's always possible to generate wrap,
> > of course. I couldn't make it happen for any window width that seemed
> > reasonable.
> 
> I should have specified more than one column.  Clearly if you're down
> to one column it's always possible to wrap, but if you have more than
> one, does the code always reduce the number of columns in preference
> to allowing a particularly long tag name to wrap a line?

It's supposed to do that.

I have a vague recollection that someone reported a bug where
`(window-width)' was not the right value to use if `line-number-mode' is
enabled, but I can't find it again now. (Someone should build an email
client that allows easy searching.)
-- 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/20120110/057f090a/attachment.pgp>


another attempt to add delete functionality in emacs

2012-01-10 Thread David Bremner
On Tue, 10 Jan 2012 07:47:23 +, David Edmondson  wrote:
> On Sat,  7 Jan 2012 14:28:10 -0800, Jameson Graef Rollins  finestructure.net> wrote:
> > I try to address the concerns that have come up in previous attempts.
> > In particular, I include a patch that creates a new customization
> > variable, notmuch-search-exclude-deleted, that will exclude any
> > messages with the "deleted" tag from searches.  

[snip]

> I honestly don't understand the reason for this. If someone wants to not
> see messages that they have tagged as 'deleted', they add 'and not
> tag:deleted' to the end of the search expression.

Just thinking out loud here, but it does seem a bit unfortunate to me
that it represents a pretty fundamental divergence between the CLI and
the emacs interface. Mind you, I guess one could make the same argument
about the libs versus the CLI. Lack of configuration information in the
library (possibly among other reasons) makes this not too nice to
support in the current library either.

d



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

2012-01-10 Thread David Edmondson
On Tue, 10 Jan 2012 10:36:50 -0500, Austin Clements  wrote:
> LGTM, though would it be easier to put this in the else clause of the
> if after the setq count?

Agreed. I got confused thinking about it due to the empty elements in
the matrix, but perhaps that doesn't matter. I'll continue to think, but
would rather not delay fixing the bug.

> Is it possible for a tag in the last column to be just long enough to
> make the line still wrap?  Somehow my current tag set doesn't trigger
> this bug, so I can't test this case (and I admit I can't follow
> notmuch-hello-insert-tags well enough to reason this out).

With a sufficiently narrow window it's always possible to generate wrap,
of course. I couldn't make it happen for any window width that seemed
reasonable.
-- 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/20120110/c0543dc2/attachment.pgp>


[PATCH 2/3 v2] test: Add tests for `notmuch-show-clean-address'.

2012-01-10 Thread David Edmondson
On Tue, 10 Jan 2012 07:06:58 -0400, David Bremner  wrote:
> On Fri, 30 Dec 2011 09:39:37 +, David Edmondson  wrote:
> > ---
> > 
> > Added backslash test. UTF8 round-trip still isn't right.
> > 
> 
> Do you mind explaining a bit better in the commit message what the issue
> is here?

I'm not completely sure.

The expected output file is supposed to contain some UTF8 encoded
text. One of the addresses to be tested has a 'human readable' part that
has the same UTF8 text. Testing the functions directly within emacs
retains the text correctly encoded. Pushing the text through the test
suite results in text that does not correctly match the expected
output.

There are many places where things could be wrong:
  - the expected output file doesn't include the correct UTF8 text
(but it looks fine in emacs),
  - the test wrapper script doesn't correctly pass around the UTF8
encoded text,
  - the emacs reader is not correctly loading the UTF8 encoded text,
  - .
-- 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/20120110/2a6e139c/attachment-0001.pgp>


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

2012-01-10 Thread Austin Clements
Quoth David Edmondson on Jan 10 at  3:47 pm:
> On Tue, 10 Jan 2012 10:36:50 -0500, Austin Clements  
> wrote:
> > LGTM, though would it be easier to put this in the else clause of the
> > if after the setq count?
> 
> Agreed. I got confused thinking about it due to the empty elements in
> the matrix, but perhaps that doesn't matter. I'll continue to think, but
> would rather not delay fixing the bug.

Fair enough.

> > Is it possible for a tag in the last column to be just long enough to
> > make the line still wrap?  Somehow my current tag set doesn't trigger
> > this bug, so I can't test this case (and I admit I can't follow
> > notmuch-hello-insert-tags well enough to reason this out).
> 
> With a sufficiently narrow window it's always possible to generate wrap,
> of course. I couldn't make it happen for any window width that seemed
> reasonable.

I should have specified more than one column.  Clearly if you're down
to one column it's always possible to wrap, but if you have more than
one, does the code always reduce the number of columns in preference
to allowing a particularly long tag name to wrap a line?  Based on
your testing, it sounds like it handles this correctly.  (Even if it
didn't, this shouldn't block this patch; it's related, but not the
same issue.)


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

2012-01-10 Thread Austin Clements
LGTM, though would it be easier to put this in the else clause of the
if after the setq count?

Is it possible for a tag in the last column to be just long enough to
make the line still wrap?  Somehow my current tag set doesn't trigger
this bug, so I can't test this case (and I admit I can't follow
notmuch-hello-insert-tags well enough to reason this out).

Quoth David Edmondson on Jan 10 at 10:15 am:
> 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.
> 
> Hence, avoid padding the last column on each row.
> ---
> 
> Thanks to j4ni in #notmuch for spotting this.
> 
>  emacs/notmuch-hello.el |   20 +++-
>  1 files changed, 11 insertions(+), 9 deletions(-)
> 
> diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
> index 333d4c1..02017ce 100644
> --- a/emacs/notmuch-hello.el
> +++ b/emacs/notmuch-hello.el
> @@ -299,15 +299,17 @@ should be. Returns a cons cell `(tags-per-line width)'."
>  :notify #'notmuch-hello-widget-search
>  :notmuch-search-terms query
>  formatted-name)
> - ;; Insert enough space to consume the rest of the
> - ;; column.  Because the button for the name is `(1+
> - ;; (length name))' long (due to the trailing space) we
> - ;; can just insert `(- widest (length name))' spaces -
> - ;; the column separator is included in the button if
> - ;; `(equal widest (length name)'.
> - (widget-insert (make-string (max 1
> -  (- widest (length name)))
> - ? 
> + (unless (eq (% count tags-per-line) (1- tags-per-line))
> +   ;; If this is not the last tag on the line, insert
> +   ;; enough space to consume the rest of the column.
> +   ;; Because the button for the name is `(1+ (length
> +   ;; name))' long (due to the trailing space) we can
> +   ;; just insert `(- widest (length name))' spaces - the
> +   ;; column separator is included in the button if
> +   ;; `(equal widest (length name)'.
> +   (widget-insert (make-string (max 1
> +(- widest (length name)))
> +   ? )
>   (setq count (1+ count))
>   (if (eq (% count tags-per-line) 0)
>   (widget-insert "\n")))


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

2012-01-10 Thread David Edmondson
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.

Hence, avoid padding the last column on each row.
---

Thanks to j4ni in #notmuch for spotting this.

 emacs/notmuch-hello.el |   20 +++-
 1 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index 333d4c1..02017ce 100644
--- a/emacs/notmuch-hello.el
+++ b/emacs/notmuch-hello.el
@@ -299,15 +299,17 @@ should be. Returns a cons cell `(tags-per-line width)'."
   :notify #'notmuch-hello-widget-search
   :notmuch-search-terms query
   formatted-name)
-   ;; Insert enough space to consume the rest of the
-   ;; column.  Because the button for the name is `(1+
-   ;; (length name))' long (due to the trailing space) we
-   ;; can just insert `(- widest (length name))' spaces -
-   ;; the column separator is included in the button if
-   ;; `(equal widest (length name)'.
-   (widget-insert (make-string (max 1
-(- widest (length name)))
-   ? 
+   (unless (eq (% count tags-per-line) (1- tags-per-line))
+ ;; If this is not the last tag on the line, insert
+ ;; enough space to consume the rest of the column.
+ ;; Because the button for the name is `(1+ (length
+ ;; name))' long (due to the trailing space) we can
+ ;; just insert `(- widest (length name))' spaces - the
+ ;; column separator is included in the button if
+ ;; `(equal widest (length name)'.
+ (widget-insert (make-string (max 1
+  (- widest (length name)))
+ ? )
(setq count (1+ count))
(if (eq (% count tags-per-line) 0)
(widget-insert "\n")))
-- 
1.7.7.3



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

2012-01-10 Thread David Bremner
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.
---
 notmuch-reply.c |  160 +-
 1 files changed, 74 insertions(+), 86 deletions(-)

diff --git a/notmuch-reply.c b/notmuch-reply.c
index 000f6da..00c9923 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -32,17 +32,17 @@ reply_part_content (GMimeObject *part);

 static const notmuch_show_format_t format_reply = {
 "",
-   "", NULL,
-   "", NULL, reply_headers_message_part, ">\n",
-   "",
-   NULL,
-   NULL,
-   NULL,
-   reply_part_content,
-   NULL,
-   "",
-   "",
-   "", "",
+"", NULL,
+"", NULL, reply_headers_message_part, ">\n",
+"",
+NULL,
+NULL,
+NULL,
+reply_part_content,
+NULL,
+"",
+"",
+"", "",
 ""
 };

@@ -54,14 +54,14 @@ show_reply_headers (GMimeMessage *message)
 stream_stdout = g_mime_stream_file_new (stdout);
 if (stream_stdout) {
g_mime_stream_file_set_owner (GMIME_STREAM_FILE (stream_stdout), FALSE);
-   stream_filter = g_mime_stream_filter_new(stream_stdout);
+   stream_filter = g_mime_stream_filter_new (stream_stdout);
if (stream_filter) {
-   g_mime_stream_filter_add(GMIME_STREAM_FILTER(stream_filter),
-g_mime_filter_headers_new());
-   g_mime_object_write_to_stream(GMIME_OBJECT(message), 
stream_filter);
-   g_object_unref(stream_filter);
+   g_mime_stream_filter_add (GMIME_STREAM_FILTER (stream_filter),
+ g_mime_filter_headers_new ());
+   g_mime_object_write_to_stream (GMIME_OBJECT (message), 
stream_filter);
+   g_object_unref (stream_filter);
}
-   g_object_unref(stream_stdout);
+   g_object_unref (stream_stdout);
 }
 }

@@ -94,18 +94,13 @@ reply_part_content (GMimeObject *part)
 GMimeContentDisposition *disposition = 
g_mime_object_get_content_disposition (part);

 if (g_mime_content_type_is_type (content_type, "multipart", "*") ||
-   g_mime_content_type_is_type (content_type, "message", "rfc822"))
-{
+   g_mime_content_type_is_type (content_type, "message", "rfc822")) {
/* Output nothing, since multipart subparts will be handled 
individually. */
-}
-else if (g_mime_content_type_is_type (content_type, "application", 
"pgp-encrypted") ||
-g_mime_content_type_is_type (content_type, "application", 
"pgp-signature"))
-{
+} else if (g_mime_content_type_is_type (content_type, "application", 
"pgp-encrypted") ||
+  g_mime_content_type_is_type (content_type, "application", 
"pgp-signature")) {
/* Ignore PGP/MIME cruft parts */
-}
-else if (g_mime_content_type_is_type (content_type, "text", "*") &&
-   !g_mime_content_type_is_type (content_type, "text", "html"))
-{
+} else if (g_mime_content_type_is_type (content_type, "text", "*") &&
+  !g_mime_content_type_is_type (content_type, "text", "html")) {
GMimeStream *stream_stdout = NULL, *stream_filter = NULL;
GMimeDataWrapper *wrapper;
const char *charset;
@@ -114,33 +109,28 @@ reply_part_content (GMimeObject *part)
stream_stdout = g_mime_stream_file_new (stdout);
if (stream_stdout) {
g_mime_stream_file_set_owner (GMIME_STREAM_FILE (stream_stdout), 
FALSE);
-   stream_filter = g_mime_stream_filter_new(stream_stdout);
+   stream_filter = g_mime_stream_filter_new (stream_stdout);
if (charset) {
-   g_mime_stream_filter_add(GMIME_STREAM_FILTER(stream_filter),
-g_mime_filter_charset_new(charset, 
"UTF-8"));
+   g_mime_stream_filter_add (GMIME_STREAM_FILTER (stream_filter),
+ g_mime_filter_charset_new (charset, 
"UTF-8"));
}
}
-   g_mime_stream_filter_add(GMIME_STREAM_FILTER(stream_filter),
-g_mime_filter_reply_new(TRUE));
+   g_mime_stream_filter_add (GMIME_STREAM_FILTER (stream_filter),
+ g_mime_filter_reply_new (TRUE));
wrapper = g_mime_part_get_content_object (GMIME_PART (part));
if (wrapper && stream_filter)
g_mime_data_wrapper_write_to_stream (wrapper, stream_filter);
if (stream_filter)
-   g_object_unref(stream_filter);
+   g_object_unref (stream_filter);
if (stream_stdout)
-   g_object_unref(stream_stdout);
-}
-else
-{
+   g_object_unref (stream_stdout);
+} else {
if (disposition &&
-   strcmp (disposition->disposition, GMIME_DISPOSITION_ATTACHMENT) == 
0)
-   {
+   

[PATCH 1/2] uncrustify.cfg: initial support for notmuch coding style

2012-01-10 Thread David Bremner
From: David Bremner 

Uncrustify is a free (as in GPL2+) tool that indents and beautifies
C/C++ code. It is similar to GNU indent in functionality although
probably more configurable (in fairness, indent has better
documentation).  Uncrustify does not have the indent mis-feature of
needing to have every typedef'ed type defined in the
configuration (even standard types like size_t).

This configuration starts with the linux-kernel style from the
uncrustify config, disables aggressive re-indenting of structs,
and fine tunes the handling 'else' and braces.

In an ideal situation, running uncrustify on notmuch code would be
NOP; currently this is not true for all files because 1) the
configuration is not perfect 2) the coding style of notmuch is not
completely consistent; in particular the treatment of braces after
e.g. for (_) is not consistent.
---
 uncrustify.cfg |   99 
 1 files changed, 99 insertions(+), 0 deletions(-)
 create mode 100644 uncrustify.cfg

diff --git a/uncrustify.cfg b/uncrustify.cfg
new file mode 100644
index 000..6613425
--- /dev/null
+++ b/uncrustify.cfg
@@ -0,0 +1,99 @@
+#
+# uncrustify config file for the linux kernel
+#
+# $Id: linux-indent.cfg 488 2006-09-09 12:44:38Z bengardner $
+# Taken from the uncrustify distribution under license (GPL2+)
+#
+# sample usage:
+#uncrustify --replace -c uncrustify.cfg foo.c
+#
+#
+
+indent_with_tabs   = 2 # 1=indent to level only, 2=indent with 
tabs
+align_with_tabs= TRUE  # use tabs to align
+align_on_tabstop   = TRUE  # align on tabstops
+input_tab_size = 8 # original tab size
+output_tab_size= 8 # new tab size
+indent_columns = 4
+
+indent_label   = 2 # pos: absolute col, neg: relative 
column
+
+
+#
+# inter-symbol newlines
+#
+
+nl_enum_brace  = remove# "enum {" vs "enum \n {"
+nl_union_brace = remove# "union {" vs "union \n {"
+nl_struct_brace= remove# "struct {" vs "struct \n {"
+nl_do_brace = remove   # "do {" vs "do \n {"
+nl_if_brace = remove   # "if () {" vs "if () \n {"
+nl_for_brace= remove   # "for () {" vs "for () \n {"
+nl_else_brace   = remove   # "else {" vs "else \n {"
+nl_while_brace  = remove   # "while () {" vs "while () \n {"
+nl_switch_brace = remove   # "switch () {" vs "switch () \n {"
+nl_brace_while = remove# "} while" vs "} \n while" - cuddle 
while
+nl_brace_else  = remove# "} else" vs "} \n else" - cuddle else
+nl_func_var_def_blk= 1
+nl_fcall_brace = remove# "list_for_each() {" vs 
"list_for_each()\n{"
+nl_fdef_brace  = force # "int foo() {" vs "int foo()\n{"
+# nl_after_return  = TRUE;
+# nl_before_case   = 1
+
+# Add or remove newline between return type and function name in definition
+nl_func_type_name  = force
+
+#
+# Source code modifications
+#
+
+# mod_paren_on_return  = remove# "return 1;" vs "return (1);"
+# mod_full_brace_if= remove# "if (a) a--;" vs "if (a) { a--; }"
+# mod_full_brace_for   = remove# "for () a--;" vs "for () { a--; }"
+# mod_full_brace_do= remove# "do a--; while ();" vs "do { a--; } 
while ();"
+# mod_full_brace_while = remove# "while (a) a--;" vs "while (a) { a--; 
}"
+
+
+#
+# inter-character spacing options
+#
+
+# sp _return_paren = force # "return (1);" vs "return(1);"
+sp_sizeof_paren= remove# "sizeof (int)" vs 
"sizeof(int)"
+sp_before_sparen   = force # "if (" vs "if("
+sp_after_sparen= force # "if () {" vs "if (){"
+sp_sparen_brace= force
+sp_after_cast  = force # "(int) a" vs "(int)a"
+sp_inside_braces   = add   # "{ 1 }" vs "{1}"
+sp_inside_braces_struct= add   # "{ 1 }" vs "{1}"
+sp_inside_braces_enum  = add   # "{ 1 }" vs "{1}"
+sp_assign  = force
+sp_arith   = force
+sp_bool= add
+sp_compare = add
+sp_assign  = add
+sp_after_comma = add
+sp_func_def_paren  = force # "int foo (){" vs "int foo(){"
+sp_func_call_paren = force # "foo (" vs "foo("
+sp_func_proto_paren= force # "int foo ();" vs "int foo();"
+sp_brace_else  = force # "} else" vs "}else"
+sp_else_brace  = force # "else {" vs "else{"
+#
+# Aligning stuff
+#
+
+align_enum_equ_span= 4 # '=' in enum definition
+# align_nl_cont= TRUE
+# align_var_def_span   = 2
+# align_var_def_inline = TRUE
+# align_var_def_star   = FALSE
+# align_var_def_colon  = TRUE
+# align_assign_span= 1
+align_struct_init_span = 0 # 

No subject

2012-01-10 Thread David Bremner
After a little fine-tuning, and some consensus about brace style on
the list, I think this is getting pretty useful. I attach a demo
uncrustification, where IMHO the output is mostly good.  Note that it
catches some style mistakes in quite recent changes.

One thing I wondered about where to put put the file; the top
directory starts to become a bit cluttered. One possibility is to make
a directory called something like HACKING/ which has files intended
for developers in it (so RELEASING could go there, along with any
coding style guides, maybe a version of the patch preparation guide),
and put uncrustify.cfg there.



change to default archive/delete key bindings

2012-01-10 Thread David Edmondson
On Sat,  7 Jan 2012 17:26:51 -0800, Jameson Graef Rollins  wrote:
> While working on the delete message handling patches, I was reminded
> how much I really dislike the default show-mode key bindings.  Why
> can't I just archive/delete the current message, without archiving the
> entire thread?  It doesn't make any sense.
> 
> Here we add two new functions to archive and delete just the single
> message, and then move to the next open message.  We also add an
> option to the -next-open-message function so that it will pop back out
> to the parent search buffer when reaching the end of the thread.  This
> should make message processing flow much smoother.

This seems good to me, though it will confuse me for a while when first
introduced :-/
-- 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/20120110/e6bb92c9/attachment.pgp>


another attempt to add delete functionality in emacs

2012-01-10 Thread David Edmondson
On Sat,  7 Jan 2012 14:28:10 -0800, Jameson Graef Rollins  wrote:
> I try to address the concerns that have come up in previous attempts.
> In particular, I include a patch that creates a new customization
> variable, notmuch-search-exclude-deleted, that will exclude any
> messages with the "deleted" tag from searches.  This actually makes
> "deleted" messages appear effectively deleted, which is one of the
> things cworth wanted to see, and one of the reasons he kept pushing
> back on previous attempts at this functionality.

I honestly don't understand the reason for this. If someone wants to not
see messages that they have tagged as 'deleted', they add 'and not
tag:deleted' to the end of the search expression.

The messages aren't actually deleted because they have the 'deleted'
tag, so why would they not be shown?

If it's really intended that those messages not be shown then perhaps
the tag should be called 'not-shown' or something.

> Also, no tags other than "deleted" are modified.  All tags should be
> orthogonal, and should be handled so.

+1

The name 'deleted' for the tag should be a configuration option, as a
non-English speaker (for example) might want to use something else.
-- 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/20120110/3ab755cf/attachment-0001.pgp>


[PATCH 1/4 v2] emacs: add show-mode functions to archive/delete only current message

2012-01-10 Thread David Edmondson
On Sun,  8 Jan 2012 11:09:09 -0800, Jameson Graef Rollins  wrote:
> This adds two new function, notmuch-show-{archive,delete}-message,
> that archive/delete the current message, and then move to the next
> open one.

Looks fine.
-- 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/20120110/038cedd1/attachment-0001.pgp>


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

2012-01-10 Thread David Edmondson
On Mon, 9 Jan 2012 19:10:48 -0700, Adam Wolfe Gordon  wrote:
> > 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?

My suggestion would be to move the `html to text' functionality to a new
.el, as we might have more than one way to achieve it (emacs 24 has
`shr', for example).

Have `notmuch-mua.el' use a generically named function to perform the
transformation from html to text and that function should determine the
best way to achieve it.

Testing for `w3m.el' is relatively easy (`require' it and check for
error). Testing for `w3m' itself can be done using some code similar to
`notmuch-address-locate-command' (search the list - it's not yet
integrated), which is itself just copied from w3m (and should end up in
`notmuch-lib.el').
-- 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/20120110/1da5c38a/attachment-0001.pgp>


[PATCH] Properly handle short writes in sigint handlers

2012-01-10 Thread David Bremner
On Fri, 23 Dec 2011 23:10:35 +0400, Dmitry Kurochkin  wrote:
> Hi Austin.
> 
> I think we should put the write loop into a separate function and reuse
> it.

I could go either way on this, unless there is somewhere else the code
is actually needed at the moment.

> 
> Also, does it make sense to add a retry counter to prevent infinite loop
> if write keeps returning 0?

I wonder about this too. Is this possibility ignorable Austin?

d


[PATCH 2/3 v2] test: Add tests for `notmuch-show-clean-address'.

2012-01-10 Thread David Bremner
On Fri, 30 Dec 2011 09:39:37 +, David Edmondson  wrote:
> ---
> 
> Added backslash test. UTF8 round-trip still isn't right.
> 

Hi David.

Do you mind explaining a bit better in the commit message what the issue
is here?

d


[PATCH] emacs: Mark the quoted region during reply.

2012-01-10 Thread David Bremner
On Fri,  6 Jan 2012 10:03:40 +, David Edmondson  wrote:
> Mark the quoted region of text during a reply, making it easy for the
> user to delete it quickly.

Pushed to master.

d


[PATCH] man: add missing SEE ALSO header to notmuch reply man page

2012-01-10 Thread David Bremner
On Sun,  8 Jan 2012 22:57:22 +0200, Jani Nikula  wrote:
> Signed-off-by: Jani Nikula 
> ---
>  man/man1/notmuch-reply.1 |3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)

Pushed to master

d


[RFC PATCH 3/9] lib: fix messages.c build warn

2012-01-10 Thread David Bremner
On Sun,  8 Jan 2012 01:26:17 +0200, Jani Nikula  wrote:
> lib/messages.c: In function ?notmuch_messages_move_to_next?:
> lib/messages.c:131:2: warning: ISO C forbids ?return? with expression, in 
> function returning void [-pedantic]

Pushed to master.

d


Distributed Notmuch

2012-01-10 Thread Jan Pobrislo
Quoting Ethan Glasser-Camp (2012-01-08 11:23:59)
>Hi guys,
>
> ...
>
>In brainstorming about the One True Mail Setup, my friend suggested to 
>me that Maildir/IMAP are not really the best choices for mail storage. 

In my opinion Maildirs are very good mail storage format, the issue is
just that IMAP can't transfer them in their entirety and simplicity.

>Among other flaws: to synchronize mail via IMAP you have to check the 
>headers of each message, which means a lot of bandwidth;

There are UIDs in IMAP, see:
http://tools.ietf.org/html/rfc3501#section-2.3.1.1
But I do agree IMAP is indeed not a very good protocol.

>compress Maildir, meaning lots of wasted space;

There are several approaches to compressing the filesystem that can be
used with maildirs, but this could easilly become bottleneck for most
setups.

>My friend suggested that instead it might be better to dump mail into
>some kind of database, for example CouchDB, and synchronize it that way. 

Some time ago I pondered putting emails into MongoDB so the client does
not have to deal with parsing MIME, but this does not give you any big
advantage for synchronization. Rather, you'll be running into the
consistency/availability/partition-tolerance issue. You'll have to
choose if you want to support offline write operations and if so, how
will you handle conflicts that will appear. DVCSes are built to make
this as easy as possible, databases usually not. I cannot comment on
CouchDB and it's MVCC, but I still doubt it would be as practical as
true DVCS.

By the way I highly reccomend this blogpost series:
http://blog.mongodb.org/post/475279604/on-distributed-consistency-part-1

> ...
>
>So my question for the wizards on this list is what their idea of the 
>One True Mail Setup would be in a perfect, or slightly better, world, 
>and what needs to be done to get there. I know some people use one 
>notmuch install that they access remotely. For myself, I'm on a pretty 
>limited Internet connection, so low bandwidth/offline access are big for 
>me, and despite Nicolas Sebrecht and Sebastian Spaeth's heroic work on 
>OfflineIMAP, it still uses a lot of bandwidth to sync. And obviously the 
>whole point of this exercise is tag synchronization..

I tend to go offline too with my laptop, so I can see what are you
talking about. For me the Ideal Mail Setup would be:

* access via ssh to limited/pseudoshell account
  - ssh handles autentication far better than sasl-based apps
  - ssh is designed to allow multiple operations in parallel including
large uploads/downloads that can be resumed
* maildir is accessible via sftp (sshfs) and ssh+rsync
* there is notmuch launchable from the restricted shell, every new mail
  is indexed
* there is database of messages, tags and filenames, kept under DVCS.
  With aid of this database full three-way merges may be performed.
* once client is connected, he should have a way to listen for change
  messages that the server will push

This would allow for convenient operation both in online (storage-free)
and offline (replicated) mode.

I think this is actually pretty implementable. I'd use twisted.conch for
ssh server (launchpad.net uses this), which can be easilly tied in with
dovecot's autentication daemon. Change detection can be done via
inotify/lsyncd. The versioning/merging tool can possibly be based off
current nmbug (I haven't examined it yet). But I'm pretty sure I won't
have time for project of such scale in near future.




Re: Python bindings for adoption

2012-01-10 Thread Jameson Graef Rollins
On Sun, 08 Jan 2012 16:16:06 -, Justus Winter 
4win...@informatik.uni-hamburg.de wrote:
 I've decided to step up as a new maintainer for the libnotmuch python
 bindings. I assume that I'll have to mail an ssh public key to someone
 for repository access, right?

That's great to hear, Justus.  Thanks for stepping up!

jamie.


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


Re: [PATCH v2 0/6] reply to sender

2012-01-10 Thread Dmitry Kurochkin
Hi Jani.

I prefer to leave the Emacs UI default reply behavior as is.

Changing it in CLI would not affect me, but I think the default should
be the same as in the Emacs UI.

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


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

2012-01-10 Thread Adam Wolfe Gordon
On Sun, Jan 8, 2012 at 18:27, Aaron Ecay aarone...@gmail.com wrote:
 +(defun w3m-region (start end)) ;; From `w3m.el'.

 What is the purpose of the above line?  If it is to make the compiler
 aware of the function, you should use ‘declare-function’ instead.  Defun
 will erase the original definition of the w3m-region function.

Indeed, it's to make the compiler aware of the function.  I followed
the example of notmuch-show.el (defvar w3m-current-buffer, line 391),
but it sounds like declare-function is a better way to accomplish
this.  I haven't written a whole lot of emacs lisp, so thanks for the
tip.

Given David's comments about requiring w3m instead it might be moot,
but if not I'll make this change for the next version.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] NEWS: add news entry for notmuch reply uninitialized variable bugfix

2012-01-10 Thread David Bremner
On Mon,  9 Jan 2012 11:49:56 +, Jani Nikula j...@nikula.org wrote:
 ---
 
 This is against release branch.
 ---

Pushed to release.

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


Re: Distributed Notmuch

2012-01-10 Thread Jan Pobrislo
Quoting Ethan Glasser-Camp (2012-01-08 11:23:59)
Hi guys,

 ...

In brainstorming about the One True Mail Setup, my friend suggested to 
me that Maildir/IMAP are not really the best choices for mail storage. 

In my opinion Maildirs are very good mail storage format, the issue is
just that IMAP can't transfer them in their entirety and simplicity.

Among other flaws: to synchronize mail via IMAP you have to check the 
headers of each message, which means a lot of bandwidth;

There are UIDs in IMAP, see:
http://tools.ietf.org/html/rfc3501#section-2.3.1.1
But I do agree IMAP is indeed not a very good protocol.

compress Maildir, meaning lots of wasted space;

There are several approaches to compressing the filesystem that can be
used with maildirs, but this could easilly become bottleneck for most
setups.

My friend suggested that instead it might be better to dump mail into
some kind of database, for example CouchDB, and synchronize it that way. 

Some time ago I pondered putting emails into MongoDB so the client does
not have to deal with parsing MIME, but this does not give you any big
advantage for synchronization. Rather, you'll be running into the
consistency/availability/partition-tolerance issue. You'll have to
choose if you want to support offline write operations and if so, how
will you handle conflicts that will appear. DVCSes are built to make
this as easy as possible, databases usually not. I cannot comment on
CouchDB and it's MVCC, but I still doubt it would be as practical as
true DVCS.

By the way I highly reccomend this blogpost series:
http://blog.mongodb.org/post/475279604/on-distributed-consistency-part-1

 ...

So my question for the wizards on this list is what their idea of the 
One True Mail Setup would be in a perfect, or slightly better, world, 
and what needs to be done to get there. I know some people use one 
notmuch install that they access remotely. For myself, I'm on a pretty 
limited Internet connection, so low bandwidth/offline access are big for 
me, and despite Nicolas Sebrecht and Sebastian Spaeth's heroic work on 
OfflineIMAP, it still uses a lot of bandwidth to sync. And obviously the 
whole point of this exercise is tag synchronization..

I tend to go offline too with my laptop, so I can see what are you
talking about. For me the Ideal Mail Setup would be:

* access via ssh to limited/pseudoshell account
  - ssh handles autentication far better than sasl-based apps
  - ssh is designed to allow multiple operations in parallel including
large uploads/downloads that can be resumed
* maildir is accessible via sftp (sshfs) and ssh+rsync
* there is notmuch launchable from the restricted shell, every new mail
  is indexed
* there is database of messages, tags and filenames, kept under DVCS.
  With aid of this database full three-way merges may be performed.
* once client is connected, he should have a way to listen for change
  messages that the server will push

This would allow for convenient operation both in online (storage-free)
and offline (replicated) mode.

I think this is actually pretty implementable. I'd use twisted.conch for
ssh server (launchpad.net uses this), which can be easilly tied in with
dovecot's autentication daemon. Change detection can be done via
inotify/lsyncd. The versioning/merging tool can possibly be based off
current nmbug (I haven't examined it yet). But I'm pretty sure I won't
have time for project of such scale in near future.

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


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

2012-01-10 Thread David Edmondson
On Mon, 9 Jan 2012 19:10:48 -0700, Adam Wolfe Gordon a...@xvx.ca wrote:
  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?

My suggestion would be to move the `html to text' functionality to a new
.el, as we might have more than one way to achieve it (emacs 24 has
`shr', for example).

Have `notmuch-mua.el' use a generically named function to perform the
transformation from html to text and that function should determine the
best way to achieve it.

Testing for `w3m.el' is relatively easy (`require' it and check for
error). Testing for `w3m' itself can be done using some code similar to
`notmuch-address-locate-command' (search the list - it's not yet
integrated), which is itself just copied from w3m (and should end up in
`notmuch-lib.el').


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


Re: another attempt to add delete functionality in emacs

2012-01-10 Thread David Edmondson
On Sat,  7 Jan 2012 14:28:10 -0800, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 I try to address the concerns that have come up in previous attempts.
 In particular, I include a patch that creates a new customization
 variable, notmuch-search-exclude-deleted, that will exclude any
 messages with the deleted tag from searches.  This actually makes
 deleted messages appear effectively deleted, which is one of the
 things cworth wanted to see, and one of the reasons he kept pushing
 back on previous attempts at this functionality.

I honestly don't understand the reason for this. If someone wants to not
see messages that they have tagged as 'deleted', they add 'and not
tag:deleted' to the end of the search expression.

The messages aren't actually deleted because they have the 'deleted'
tag, so why would they not be shown?

If it's really intended that those messages not be shown then perhaps
the tag should be called 'not-shown' or something.

 Also, no tags other than deleted are modified.  All tags should be
 orthogonal, and should be handled so.

+1

The name 'deleted' for the tag should be a configuration option, as a
non-English speaker (for example) might want to use something else.


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


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

2012-01-10 Thread David Edmondson
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.

Hence, avoid padding the last column on each row.
---

Thanks to j4ni in #notmuch for spotting this.

 emacs/notmuch-hello.el |   20 +++-
 1 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index 333d4c1..02017ce 100644
--- a/emacs/notmuch-hello.el
+++ b/emacs/notmuch-hello.el
@@ -299,15 +299,17 @@ should be. Returns a cons cell `(tags-per-line width)'.
   :notify #'notmuch-hello-widget-search
   :notmuch-search-terms query
   formatted-name)
-   ;; Insert enough space to consume the rest of the
-   ;; column.  Because the button for the name is `(1+
-   ;; (length name))' long (due to the trailing space) we
-   ;; can just insert `(- widest (length name))' spaces -
-   ;; the column separator is included in the button if
-   ;; `(equal widest (length name)'.
-   (widget-insert (make-string (max 1
-(- widest (length name)))
-   ? 
+   (unless (eq (% count tags-per-line) (1- tags-per-line))
+ ;; If this is not the last tag on the line, insert
+ ;; enough space to consume the rest of the column.
+ ;; Because the button for the name is `(1+ (length
+ ;; name))' long (due to the trailing space) we can
+ ;; just insert `(- widest (length name))' spaces - the
+ ;; column separator is included in the button if
+ ;; `(equal widest (length name)'.
+ (widget-insert (make-string (max 1
+  (- widest (length name)))
+ ? )
(setq count (1+ count))
(if (eq (% count tags-per-line) 0)
(widget-insert \n)))
-- 
1.7.7.3

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


Re: [RFC PATCH 3/9] lib: fix messages.c build warn

2012-01-10 Thread David Bremner
On Sun,  8 Jan 2012 01:26:17 +0200, Jani Nikula j...@nikula.org wrote:
 lib/messages.c: In function ‘notmuch_messages_move_to_next’:
 lib/messages.c:131:2: warning: ISO C forbids ‘return’ with expression, in 
 function returning void [-pedantic]

Pushed to master.

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


Re: [PATCH] man: add missing SEE ALSO header to notmuch reply man page

2012-01-10 Thread David Bremner
On Sun,  8 Jan 2012 22:57:22 +0200, Jani Nikula j...@nikula.org wrote:
 Signed-off-by: Jani Nikula j...@nikula.org
 ---
  man/man1/notmuch-reply.1 |3 +++
  1 files changed, 3 insertions(+), 0 deletions(-)

Pushed to master

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


Re: [PATCH] emacs: Mark the quoted region during reply.

2012-01-10 Thread David Bremner
On Fri,  6 Jan 2012 10:03:40 +, David Edmondson d...@dme.org wrote:
 Mark the quoted region of text during a reply, making it easy for the
 user to delete it quickly.

Pushed to master.

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


Re: [PATCH 2/3 v2] test: Add tests for `notmuch-show-clean-address'.

2012-01-10 Thread David Bremner
On Fri, 30 Dec 2011 09:39:37 +, David Edmondson d...@dme.org wrote:
 ---
 
 Added backslash test. UTF8 round-trip still isn't right.
 

Hi David.

Do you mind explaining a bit better in the commit message what the issue
is here?

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


Re: [PATCH] Properly handle short writes in sigint handlers

2012-01-10 Thread David Bremner
On Fri, 23 Dec 2011 23:10:35 +0400, Dmitry Kurochkin 
dmitry.kuroch...@gmail.com wrote:
 Hi Austin.
 
 I think we should put the write loop into a separate function and reuse
 it.

I could go either way on this, unless there is somewhere else the code
is actually needed at the moment.

 
 Also, does it make sense to add a retry counter to prevent infinite loop
 if write keeps returning 0?

I wonder about this too. Is this possibility ignorable Austin?

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


Re: [PATCH 2/3 v2] test: Add tests for `notmuch-show-clean-address'.

2012-01-10 Thread David Edmondson
On Tue, 10 Jan 2012 07:06:58 -0400, David Bremner da...@tethera.net wrote:
 On Fri, 30 Dec 2011 09:39:37 +, David Edmondson d...@dme.org wrote:
  ---
  
  Added backslash test. UTF8 round-trip still isn't right.
  
 
 Do you mind explaining a bit better in the commit message what the issue
 is here?

I'm not completely sure.

The expected output file is supposed to contain some UTF8 encoded
text. One of the addresses to be tested has a 'human readable' part that
has the same UTF8 text. Testing the functions directly within emacs
retains the text correctly encoded. Pushing the text through the test
suite results in text that does not correctly match the expected
output.

There are many places where things could be wrong:
  - the expected output file doesn't include the correct UTF8 text
(but it looks fine in emacs),
  - the test wrapper script doesn't correctly pass around the UTF8
encoded text,
  - the emacs reader is not correctly loading the UTF8 encoded text,
  - your favourite imagined problem here.


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


[no subject]

2012-01-10 Thread David Bremner
After a little fine-tuning, and some consensus about brace style on
the list, I think this is getting pretty useful. I attach a demo
uncrustification, where IMHO the output is mostly good.  Note that it
catches some style mistakes in quite recent changes.

One thing I wondered about where to put put the file; the top
directory starts to become a bit cluttered. One possibility is to make
a directory called something like HACKING/ which has files intended
for developers in it (so RELEASING could go there, along with any
coding style guides, maybe a version of the patch preparation guide),
and put uncrustify.cfg there.

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


[PATCH 1/2] uncrustify.cfg: initial support for notmuch coding style

2012-01-10 Thread David Bremner
From: David Bremner brem...@debian.org

Uncrustify is a free (as in GPL2+) tool that indents and beautifies
C/C++ code. It is similar to GNU indent in functionality although
probably more configurable (in fairness, indent has better
documentation).  Uncrustify does not have the indent mis-feature of
needing to have every typedef'ed type defined in the
configuration (even standard types like size_t).

This configuration starts with the linux-kernel style from the
uncrustify config, disables aggressive re-indenting of structs,
and fine tunes the handling 'else' and braces.

In an ideal situation, running uncrustify on notmuch code would be
NOP; currently this is not true for all files because 1) the
configuration is not perfect 2) the coding style of notmuch is not
completely consistent; in particular the treatment of braces after
e.g. for (_) is not consistent.
---
 uncrustify.cfg |   99 
 1 files changed, 99 insertions(+), 0 deletions(-)
 create mode 100644 uncrustify.cfg

diff --git a/uncrustify.cfg b/uncrustify.cfg
new file mode 100644
index 000..6613425
--- /dev/null
+++ b/uncrustify.cfg
@@ -0,0 +1,99 @@
+#
+# uncrustify config file for the linux kernel
+#
+# $Id: linux-indent.cfg 488 2006-09-09 12:44:38Z bengardner $
+# Taken from the uncrustify distribution under license (GPL2+)
+#
+# sample usage:
+#uncrustify --replace -c uncrustify.cfg foo.c
+#
+#
+
+indent_with_tabs   = 2 # 1=indent to level only, 2=indent with 
tabs
+align_with_tabs= TRUE  # use tabs to align
+align_on_tabstop   = TRUE  # align on tabstops
+input_tab_size = 8 # original tab size
+output_tab_size= 8 # new tab size
+indent_columns = 4
+
+indent_label   = 2 # pos: absolute col, neg: relative 
column
+
+
+#
+# inter-symbol newlines
+#
+
+nl_enum_brace  = remove# enum { vs enum \n {
+nl_union_brace = remove# union { vs union \n {
+nl_struct_brace= remove# struct { vs struct \n {
+nl_do_brace = remove   # do { vs do \n {
+nl_if_brace = remove   # if () { vs if () \n {
+nl_for_brace= remove   # for () { vs for () \n {
+nl_else_brace   = remove   # else { vs else \n {
+nl_while_brace  = remove   # while () { vs while () \n {
+nl_switch_brace = remove   # switch () { vs switch () \n {
+nl_brace_while = remove# } while vs } \n while - cuddle 
while
+nl_brace_else  = remove# } else vs } \n else - cuddle else
+nl_func_var_def_blk= 1
+nl_fcall_brace = remove# list_for_each() { vs 
list_for_each()\n{
+nl_fdef_brace  = force # int foo() { vs int foo()\n{
+# nl_after_return  = TRUE;
+# nl_before_case   = 1
+
+# Add or remove newline between return type and function name in definition
+nl_func_type_name  = force
+
+#
+# Source code modifications
+#
+
+# mod_paren_on_return  = remove# return 1; vs return (1);
+# mod_full_brace_if= remove# if (a) a--; vs if (a) { a--; }
+# mod_full_brace_for   = remove# for () a--; vs for () { a--; }
+# mod_full_brace_do= remove# do a--; while (); vs do { a--; } 
while ();
+# mod_full_brace_while = remove# while (a) a--; vs while (a) { a--; 
}
+
+
+#
+# inter-character spacing options
+#
+
+# sp _return_paren = force # return (1); vs return(1);
+sp_sizeof_paren= remove# sizeof (int) vs 
sizeof(int)
+sp_before_sparen   = force # if ( vs if(
+sp_after_sparen= force # if () { vs if (){
+sp_sparen_brace= force
+sp_after_cast  = force # (int) a vs (int)a
+sp_inside_braces   = add   # { 1 } vs {1}
+sp_inside_braces_struct= add   # { 1 } vs {1}
+sp_inside_braces_enum  = add   # { 1 } vs {1}
+sp_assign  = force
+sp_arith   = force
+sp_bool= add
+sp_compare = add
+sp_assign  = add
+sp_after_comma = add
+sp_func_def_paren  = force # int foo (){ vs int foo(){
+sp_func_call_paren = force # foo ( vs foo(
+sp_func_proto_paren= force # int foo (); vs int foo();
+sp_brace_else  = force # } else vs }else
+sp_else_brace  = force # else { vs else{
+#
+# Aligning stuff
+#
+
+align_enum_equ_span= 4 # '=' in enum definition
+# align_nl_cont= TRUE
+# align_var_def_span   = 2
+# align_var_def_inline = TRUE
+# align_var_def_star   = FALSE
+# align_var_def_colon  = TRUE
+# align_assign_span= 1
+align_struct_init_span = 0 # align stuff in a structure init '= { 
}'
+align_right_cmt_span   = 0
+# align_pp_define_span = 8;
+# align_pp_define_gap  = 4;

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

2012-01-10 Thread David Bremner
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.
---
 notmuch-reply.c |  160 +-
 1 files changed, 74 insertions(+), 86 deletions(-)

diff --git a/notmuch-reply.c b/notmuch-reply.c
index 000f6da..00c9923 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -32,17 +32,17 @@ reply_part_content (GMimeObject *part);
 
 static const notmuch_show_format_t format_reply = {
 ,
-   , NULL,
-   , NULL, reply_headers_message_part, \n,
-   ,
-   NULL,
-   NULL,
-   NULL,
-   reply_part_content,
-   NULL,
-   ,
-   ,
-   , ,
+, NULL,
+, NULL, reply_headers_message_part, \n,
+,
+NULL,
+NULL,
+NULL,
+reply_part_content,
+NULL,
+,
+,
+, ,
 
 };
 
@@ -54,14 +54,14 @@ show_reply_headers (GMimeMessage *message)
 stream_stdout = g_mime_stream_file_new (stdout);
 if (stream_stdout) {
g_mime_stream_file_set_owner (GMIME_STREAM_FILE (stream_stdout), FALSE);
-   stream_filter = g_mime_stream_filter_new(stream_stdout);
+   stream_filter = g_mime_stream_filter_new (stream_stdout);
if (stream_filter) {
-   g_mime_stream_filter_add(GMIME_STREAM_FILTER(stream_filter),
-g_mime_filter_headers_new());
-   g_mime_object_write_to_stream(GMIME_OBJECT(message), 
stream_filter);
-   g_object_unref(stream_filter);
+   g_mime_stream_filter_add (GMIME_STREAM_FILTER (stream_filter),
+ g_mime_filter_headers_new ());
+   g_mime_object_write_to_stream (GMIME_OBJECT (message), 
stream_filter);
+   g_object_unref (stream_filter);
}
-   g_object_unref(stream_stdout);
+   g_object_unref (stream_stdout);
 }
 }
 
@@ -94,18 +94,13 @@ reply_part_content (GMimeObject *part)
 GMimeContentDisposition *disposition = 
g_mime_object_get_content_disposition (part);
 
 if (g_mime_content_type_is_type (content_type, multipart, *) ||
-   g_mime_content_type_is_type (content_type, message, rfc822))
-{
+   g_mime_content_type_is_type (content_type, message, rfc822)) {
/* Output nothing, since multipart subparts will be handled 
individually. */
-}
-else if (g_mime_content_type_is_type (content_type, application, 
pgp-encrypted) ||
-g_mime_content_type_is_type (content_type, application, 
pgp-signature))
-{
+} else if (g_mime_content_type_is_type (content_type, application, 
pgp-encrypted) ||
+  g_mime_content_type_is_type (content_type, application, 
pgp-signature)) {
/* Ignore PGP/MIME cruft parts */
-}
-else if (g_mime_content_type_is_type (content_type, text, *) 
-   !g_mime_content_type_is_type (content_type, text, html))
-{
+} else if (g_mime_content_type_is_type (content_type, text, *) 
+  !g_mime_content_type_is_type (content_type, text, html)) {
GMimeStream *stream_stdout = NULL, *stream_filter = NULL;
GMimeDataWrapper *wrapper;
const char *charset;
@@ -114,33 +109,28 @@ reply_part_content (GMimeObject *part)
stream_stdout = g_mime_stream_file_new (stdout);
if (stream_stdout) {
g_mime_stream_file_set_owner (GMIME_STREAM_FILE (stream_stdout), 
FALSE);
-   stream_filter = g_mime_stream_filter_new(stream_stdout);
+   stream_filter = g_mime_stream_filter_new (stream_stdout);
if (charset) {
-   g_mime_stream_filter_add(GMIME_STREAM_FILTER(stream_filter),
-g_mime_filter_charset_new(charset, 
UTF-8));
+   g_mime_stream_filter_add (GMIME_STREAM_FILTER (stream_filter),
+ g_mime_filter_charset_new (charset, 
UTF-8));
}
}
-   g_mime_stream_filter_add(GMIME_STREAM_FILTER(stream_filter),
-g_mime_filter_reply_new(TRUE));
+   g_mime_stream_filter_add (GMIME_STREAM_FILTER (stream_filter),
+ g_mime_filter_reply_new (TRUE));
wrapper = g_mime_part_get_content_object (GMIME_PART (part));
if (wrapper  stream_filter)
g_mime_data_wrapper_write_to_stream (wrapper, stream_filter);
if (stream_filter)
-   g_object_unref(stream_filter);
+   g_object_unref (stream_filter);
if (stream_stdout)
-   g_object_unref(stream_stdout);
-}
-else
-{
+   g_object_unref (stream_stdout);
+} else {
if (disposition 
-   strcmp (disposition-disposition, GMIME_DISPOSITION_ATTACHMENT) == 
0)
-   {
+   strcmp (disposition-disposition, GMIME_DISPOSITION_ATTACHMENT) == 
0) {
const char 

Re: [PATCH] man: add missing SEE ALSO header to notmuch reply man page

2012-01-10 Thread Xavier Maillard

On Sun,  8 Jan 2012 22:57:22 +0200, Jani Nikula j...@nikula.org wrote:
 Signed-off-by: Jani Nikula j...@nikula.org
 ---
  man/man1/notmuch-reply.1 |3 +++
  1 files changed, 3 insertions(+), 0 deletions(-)

+1

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


Re: [ANNOUNCE] mutt with notmuch support

2012-01-10 Thread Jeremy Nickurak
FWIW, here's the patch I ended up using to play with this:

diff --git a/mutt_notmuch.c b/mutt_notmuch.c
index 2f21407..a07b1ba 100644
--- a/mutt_notmuch.c
+++ b/mutt_notmuch.c
@@ -636,11 +636,15 @@ char *nm_uri_from_query(CONTEXT *ctx, char *buf,
size_t bufsz)
 static notmuch_message_t *get_nm_message(notmuch_database_t *db, HEADER *hdr)
 {
        notmuch_message_t *msg;
+       notmuch_status_t r;
+
        char *id = nm_header_get_id(hdr);

        dprint(2, (debugfile, nm: find message (%s)\n, id));

-       msg = id  db ? notmuch_database_find_message(db, id) : NULL;
+       if (id  db) {
+               r = notmuch_database_find_message(db, id, msg);
+       }

        FREE(id);
        return msg;
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: change to default archive/delete key bindings

2012-01-10 Thread David Edmondson
On Sat,  7 Jan 2012 17:26:51 -0800, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 While working on the delete message handling patches, I was reminded
 how much I really dislike the default show-mode key bindings.  Why
 can't I just archive/delete the current message, without archiving the
 entire thread?  It doesn't make any sense.
 
 Here we add two new functions to archive and delete just the single
 message, and then move to the next open message.  We also add an
 option to the -next-open-message function so that it will pop back out
 to the parent search buffer when reaching the end of the thread.  This
 should make message processing flow much smoother.

This seems good to me, though it will confuse me for a while when first
introduced :-/


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


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

2012-01-10 Thread Austin Clements
LGTM, though would it be easier to put this in the else clause of the
if after the setq count?

Is it possible for a tag in the last column to be just long enough to
make the line still wrap?  Somehow my current tag set doesn't trigger
this bug, so I can't test this case (and I admit I can't follow
notmuch-hello-insert-tags well enough to reason this out).

Quoth David Edmondson on Jan 10 at 10:15 am:
 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.
 
 Hence, avoid padding the last column on each row.
 ---
 
 Thanks to j4ni in #notmuch for spotting this.
 
  emacs/notmuch-hello.el |   20 +++-
  1 files changed, 11 insertions(+), 9 deletions(-)
 
 diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
 index 333d4c1..02017ce 100644
 --- a/emacs/notmuch-hello.el
 +++ b/emacs/notmuch-hello.el
 @@ -299,15 +299,17 @@ should be. Returns a cons cell `(tags-per-line width)'.
  :notify #'notmuch-hello-widget-search
  :notmuch-search-terms query
  formatted-name)
 - ;; Insert enough space to consume the rest of the
 - ;; column.  Because the button for the name is `(1+
 - ;; (length name))' long (due to the trailing space) we
 - ;; can just insert `(- widest (length name))' spaces -
 - ;; the column separator is included in the button if
 - ;; `(equal widest (length name)'.
 - (widget-insert (make-string (max 1
 -  (- widest (length name)))
 - ? 
 + (unless (eq (% count tags-per-line) (1- tags-per-line))
 +   ;; If this is not the last tag on the line, insert
 +   ;; enough space to consume the rest of the column.
 +   ;; Because the button for the name is `(1+ (length
 +   ;; name))' long (due to the trailing space) we can
 +   ;; just insert `(- widest (length name))' spaces - the
 +   ;; column separator is included in the button if
 +   ;; `(equal widest (length name)'.
 +   (widget-insert (make-string (max 1
 +(- widest (length name)))
 +   ? )
   (setq count (1+ count))
   (if (eq (% count tags-per-line) 0)
   (widget-insert \n)))
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


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

2012-01-10 Thread David Edmondson
On Tue, 10 Jan 2012 10:36:50 -0500, Austin Clements amdra...@mit.edu wrote:
 LGTM, though would it be easier to put this in the else clause of the
 if after the setq count?

Agreed. I got confused thinking about it due to the empty elements in
the matrix, but perhaps that doesn't matter. I'll continue to think, but
would rather not delay fixing the bug.

 Is it possible for a tag in the last column to be just long enough to
 make the line still wrap?  Somehow my current tag set doesn't trigger
 this bug, so I can't test this case (and I admit I can't follow
 notmuch-hello-insert-tags well enough to reason this out).

With a sufficiently narrow window it's always possible to generate wrap,
of course. I couldn't make it happen for any window width that seemed
reasonable.


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


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

2012-01-10 Thread David Edmondson
On Tue, 10 Jan 2012 11:05:02 -0500, Austin Clements amdra...@mit.edu wrote:
   Is it possible for a tag in the last column to be just long enough to
   make the line still wrap?  Somehow my current tag set doesn't trigger
   this bug, so I can't test this case (and I admit I can't follow
   notmuch-hello-insert-tags well enough to reason this out).
  
  With a sufficiently narrow window it's always possible to generate wrap,
  of course. I couldn't make it happen for any window width that seemed
  reasonable.
 
 I should have specified more than one column.  Clearly if you're down
 to one column it's always possible to wrap, but if you have more than
 one, does the code always reduce the number of columns in preference
 to allowing a particularly long tag name to wrap a line?

It's supposed to do that.

I have a vague recollection that someone reported a bug where
`(window-width)' was not the right value to use if `line-number-mode' is
enabled, but I can't find it again now. (Someone should build an email
client that allows easy searching.)


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


Re: [PATCH v2] emacs: Cycle through notmuch buffers rather than jumping to the last.

2012-01-10 Thread David Edmondson
On Wed, 28 Dec 2011 08:29:58 +, David Edmondson d...@dme.org wrote:
 As suggested by j4ni in #notmuch, rename
 `notmuch-jump-to-recent-buffer' as `notmuch-cycle-notmuch-buffers' and
 have it behave accordingly.
 
 Consider `message-mode' buffers to be of interest.

Any reviewers?


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


[PATCH v3 1/4] cli: add support for replying just to the sender in notmuch reply

2012-01-10 Thread 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 markwalters1...@gmail.com 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 j...@nikula.org

---

Settled on --reply-to=(all|sender) per Carl's earlier suggestion
(id:87pqn5cg4g@yoom.home.cworth.org) and David's approval on IRC.
---
 man/man1/notmuch-reply.1 |   28 +++---
 notmuch-reply.c  |   70 ++---
 2 files changed, 76 insertions(+), 22 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 search-terms.
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 000f6da..7b785a7 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -170,7 +170,7 @@ address_is_users (const char *address, notmuch_config_t 
*config)
 
 /* 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'.
+ * address of 'type', if 'add' is true.
  *
  * The first address encountered that *is* the user's address will be
  * returned, (otherwise NULL is returned).
@@ -179,7 +179,8 @@ static const char *
 add_recipients_for_address_list (GMimeMessage *message,
 notmuch_config_t *config,
 GMimeRecipientType type,
-InternetAddressList *list)
+InternetAddressList *list,
+notmuch_bool_t add)
 {
 InternetAddress *address;
 int i;
@@ -197,7 +198,7 @@ add_recipients_for_address_list (GMimeMessage *message,
continue;
 
add_recipients_for_address_list (message, config,
-type, group_list);
+type, group_list, add);
} else {
InternetAddressMailbox *mailbox;
const char *name;
@@ -211,7 +212,7 @@ add_recipients_for_address_list (GMimeMessage *message,
if (address_is_users (addr, config)) {
if (ret == NULL)
ret = addr;
-   } else {
+   } else if (add) {
g_mime_message_add_recipient (message, type, name, addr);
}
}
@@ -222,7 +223,7 @@ add_recipients_for_address_list (GMimeMessage *message,
 
 /* 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'.
+ * an address of 'type', if 'add' is true.
  *
  * The first address encountered that *is* the user's address will be
  * returned, (otherwise NULL is returned).
@@ -231,7 +232,8 @@ static const char *
 add_recipients_for_string (GMimeMessage *message,
   notmuch_config_t *config,
   GMimeRecipientType type,
-  const char *recipients)
+  const char *recipients,
+  notmuch_bool_t add)
 {
 

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

2012-01-10 Thread 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 j...@nikula.org
---
 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 optional sender)
+(defun notmuch-mua-reply (query-string optional 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 optional prompt-for-sender)
+(defun notmuch-mua-new-reply (query-string optional 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 (optional 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 (optional 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 (optional 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 (optional 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 (optional 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 (optional 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 (rest args)
   Synchronously invoke \notmuch\ with the given list of arguments.
-- 
1.7.5.4

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


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

2012-01-10 Thread Jani Nikula
Change the default reply key bindings, making 'r' reply-to-sender and 'R'
reply-to-all.

Signed-off-by: Jani Nikula j...@nikula.org

---

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

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


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

2012-01-10 Thread Jani Nikula
From: Mark Walters markwalters1...@gmail.com

---
 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 sen...@example.com' \
+ [to]=test_su...@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 
test_su...@notmuchmail.org
+Subject: Re: notmuch-reply-test
+To: Sender sen...@example.com
+In-Reply-To: ${gen_msg_id}
+References: ${gen_msg_id}
+
+On Tue, 05 Jan 2010 15:43:56 -, Sender sen...@example.com wrote:
+ basic reply-to-sender test
+
+test_begin_subtest From Us, Basic reply to message
+add_message '[from]=Notmuch Test Suite test_su...@notmuchmail.org' \
+'[to]=Recipient recipi...@example.com' \
+ [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 
test_su...@notmuchmail.org
+Subject: Re: notmuch-reply-test
+To: Recipient recipi...@example.com
+In-Reply-To: ${gen_msg_id}
+References: ${gen_msg_id}
+
+On Tue, 05 Jan 2010 15:43:56 -, Notmuch Test Suite 
test_su...@notmuchmail.org wrote:
+ basic reply-to-from-us test
+
+test_begin_subtest Multiple recipients
+add_message '[from]=Sender sen...@example.com' \
+'[to]=test_su...@notmuchmail.org, Someone Else 
some...@example.com' \
+ [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 
test_su...@notmuchmail.org
+Subject: Re: notmuch-reply-test
+To: Sender sen...@example.com
+In-Reply-To: ${gen_msg_id}
+References: ${gen_msg_id}
+
+On Tue, 05 Jan 2010 15:43:56 -, Sender sen...@example.com wrote:
+ Multiple recipients
+
+test_begin_subtest From Us, Multiple TO recipients
+add_message '[from]=Notmuch Test Suite test_su...@notmuchmail.org' \
+'[to]=Recipient recipi...@example.com, Someone Else 
some...@example.com' \
+ [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 
test_su...@notmuchmail.org
+Subject: Re: notmuch-reply-test
+To: Recipient recipi...@example.com, Someone Else some...@example.com
+In-Reply-To: ${gen_msg_id}
+References: ${gen_msg_id}
+
+On Tue, 05 Jan 2010 15:43:56 -, Notmuch Test Suite 
test_su...@notmuchmail.org wrote:
+ From Us, Multiple TO recipients
+
+test_begin_subtest Reply with CC
+add_message '[from]=Sender sen...@example.com' \
+ [to]=test_su...@notmuchmail.org \
+'[cc]=Other Parties c...@example.com' \
+ [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 
test_su...@notmuchmail.org
+Subject: Re: notmuch-reply-test
+To: Sender sen...@example.com
+In-Reply-To: ${gen_msg_id}
+References: ${gen_msg_id}
+
+On Tue, 05 Jan 2010 15:43:56 -, Sender sen...@example.com wrote:
+ reply with CC
+
+test_begin_subtest From Us, Reply with CC
+add_message '[from]=Notmuch Test Suite test_su...@notmuchmail.org' \
+'[to]=Recipient recipi...@example.com' \
+'[cc]=Other Parties c...@example.com' \
+ [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 
test_su...@notmuchmail.org
+Subject: Re: notmuch-reply-test
+To: Recipient recipi...@example.com
+In-Reply-To: ${gen_msg_id}
+References: ${gen_msg_id}
+
+On Tue, 05 Jan 2010 15:43:56 -, Notmuch Test Suite 

Re: another attempt to add delete functionality in emacs

2012-01-10 Thread David Bremner
On Tue, 10 Jan 2012 07:47:23 +, David Edmondson d...@dme.org wrote:
 On Sat,  7 Jan 2012 14:28:10 -0800, Jameson Graef Rollins 
 jroll...@finestructure.net wrote:
  I try to address the concerns that have come up in previous attempts.
  In particular, I include a patch that creates a new customization
  variable, notmuch-search-exclude-deleted, that will exclude any
  messages with the deleted tag from searches.  

[snip]

 I honestly don't understand the reason for this. If someone wants to not
 see messages that they have tagged as 'deleted', they add 'and not
 tag:deleted' to the end of the search expression.

Just thinking out loud here, but it does seem a bit unfortunate to me
that it represents a pretty fundamental divergence between the CLI and
the emacs interface. Mind you, I guess one could make the same argument
about the libs versus the CLI. Lack of configuration information in the
library (possibly among other reasons) makes this not too nice to
support in the current library either.

d

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


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

2012-01-10 Thread Jani Nikula
On Tue, 10 Jan 2012 10:15:28 +, David Edmondson d...@dme.org 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.
 
 Hence, avoid padding the last column on each row.
 ---
 
 Thanks to j4ni in #notmuch for spotting this.

Thanks for fixing this. This patch works for me.

BR,
j4ni.


 
  emacs/notmuch-hello.el |   20 +++-
  1 files changed, 11 insertions(+), 9 deletions(-)
 
 diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
 index 333d4c1..02017ce 100644
 --- a/emacs/notmuch-hello.el
 +++ b/emacs/notmuch-hello.el
 @@ -299,15 +299,17 @@ should be. Returns a cons cell `(tags-per-line width)'.
  :notify #'notmuch-hello-widget-search
  :notmuch-search-terms query
  formatted-name)
 - ;; Insert enough space to consume the rest of the
 - ;; column.  Because the button for the name is `(1+
 - ;; (length name))' long (due to the trailing space) we
 - ;; can just insert `(- widest (length name))' spaces -
 - ;; the column separator is included in the button if
 - ;; `(equal widest (length name)'.
 - (widget-insert (make-string (max 1
 -  (- widest (length name)))
 - ? 
 + (unless (eq (% count tags-per-line) (1- tags-per-line))
 +   ;; If this is not the last tag on the line, insert
 +   ;; enough space to consume the rest of the column.
 +   ;; Because the button for the name is `(1+ (length
 +   ;; name))' long (due to the trailing space) we can
 +   ;; just insert `(- widest (length name))' spaces - the
 +   ;; column separator is included in the button if
 +   ;; `(equal widest (length name)'.
 +   (widget-insert (make-string (max 1
 +(- widest (length name)))
 +   ? )
   (setq count (1+ count))
   (if (eq (% count tags-per-line) 0)
   (widget-insert \n)))
 -- 
 1.7.7.3
 
 ___
 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 v2] emacs: Cycle through notmuch buffers rather than jumping to the last.

2012-01-10 Thread Jani Nikula
On Tue, 10 Jan 2012 16:55:07 +, David Edmondson d...@dme.org wrote:
 On Wed, 28 Dec 2011 08:29:58 +, David Edmondson d...@dme.org wrote:
  As suggested by j4ni in #notmuch, rename
  `notmuch-jump-to-recent-buffer' as `notmuch-cycle-notmuch-buffers' and
  have it behave accordingly.
  
  Consider `message-mode' buffers to be of interest.
 
 Any reviewers?

I don't feel qualified to review, but the patch works for me.

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


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

2012-01-10 Thread Jani Nikula
On Tue, 10 Jan 2012 22:41:49 +0200, Jani Nikula j...@nikula.org wrote:
 On Tue, 10 Jan 2012 16:18:21 +, David Edmondson d...@dme.org wrote:
  I have a vague recollection that someone reported a bug where
  `(window-width)' was not the right value to use if `line-number-mode' is
  enabled, but I can't find it again now. (Someone should build an email
  client that allows easy searching.)
 
 Do you perhaps mean this: id:87k47nlpzb.fsf@nausicaa.localdomain

[Now also to the list. Got bitten by my own patch binding 'r' to
reply-to-sender. Perhaps it's really too drastic to change that now...]
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: another attempt to add delete functionality in emacs

2012-01-10 Thread Jameson Graef Rollins
On Tue, 10 Jan 2012 07:47:23 +, David Edmondson d...@dme.org wrote:
 I honestly don't understand the reason for this. If someone wants to not
 see messages that they have tagged as 'deleted', they add 'and not
 tag:deleted' to the end of the search expression.

Adding and not tag:deleted in all of your searches vs. having it done
automatically?  That a pretty big usability difference to me.

The config variable is included so that people can turn the
functionality on or off as they see fit.

jamie.


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


Re: [PATCH 2/4] emacs: repurpose notmuch-show-archive-thread-internal function for general thread tagging

2012-01-10 Thread Jameson Graef Rollins
On Mon, 09 Jan 2012 00:02:20 -0500, Aaron Ecay aarone...@gmail.com wrote:
 On Sun, 08 Jan 2012 18:49:56 -0800, Jameson Graef Rollins 
 jroll...@finestructure.net wrote:
  On Sun, 08 Jan 2012 20:08:59 -0500, Aaron Ecay aarone...@gmail.com wrote:
  
   - It would be good to make show-next optional.  This will enable code
 to call the fn with only two arguments, and not showing next will be
 the default behavior.
  
  That's a nice idea.  Probably better for a separate patch, though.
 
 This patch introduces show-next as a new argument to the function.  So it
 can and should make it optional, if that is the appropriate semantics
 for it to have.

Actually, the show-next argument was already part of the function.  I
did not introduce it.  And it wasn't optional originally, so if we want
to change that behavior we should probably do so in a separate patch.

 That said, here’s an alternate proposal: provide two functions as the
 “external” API, namely ‘notmuch-show-{add,remove}-tag-thread’ (by
 parallelism with ‘notmuch-show-{add,remove}-tag’).  These could be
 thin wrappers around ‘notmuch-show-tag-thread-internal’, which would
 then not be intended to be called by user code.

I think that's a better idea.  In the next version I'll add something
like this instead.

jamie.


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


Re: another attempt to add delete functionality in emacs

2012-01-10 Thread Jameson Graef Rollins
On Tue, 10 Jan 2012 16:01:32 -0400, David Bremner da...@tethera.net wrote:
 Just thinking out loud here, but it does seem a bit unfortunate to me
 that it represents a pretty fundamental divergence between the CLI and
 the emacs interface. Mind you, I guess one could make the same argument
 about the libs versus the CLI. Lack of configuration information in the
 library (possibly among other reasons) makes this not too nice to
 support in the current library either.

I think a consensus has formed that this functionality (automatically
suppressing messages with certain tags from searches) is better left to
the CLI, rather than implementing it just in the emacs UI.
Unfortunately I'm not going to get to that any time soon.

However, without that functionality, I really see no reason why we
should be adding any built-in support for adding deleted tags in the
emacs UI.  Without the CLI change, deleted tags aren't handled any
differently than any other tag, so why should the default emacs UI care.
If users want to bind keys to special tagging operations, they can do so
for themselves [0].

In fact, I'm now starting to think we don't need to add any support for
special tagging operations (such as deleted) even if we *do* have
support for suppressing them in the CLI.  Special tagging operations
should only be supported if the tagged messages are somehow handled
specially.  If not, then again, we should just leave them up to the user
[0].

All that said, I think I'll just resubmit the couple small changes to
the emacs UI that I think we should consider adopting anyway.

jamie.


[0]
(define-key notmuch-show-mode-map d
  (lambda ()
Delete message
(interactive)
(notmuch-show-add-tag deleted)
(notmuch-show-next-open-message)))


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


[PATCH 0/3] Automatic tag-based exclusion

2012-01-10 Thread Austin Clements
This implements essentially the same idea as Jamie's patch, but does
it in the library/CLI and operates on the parsed query rather than
using an ad hoc regexp.  Which tags are automatically excluded is set
in the config file and defaults to deleted and spam.

My comment for the config file is clunky.  I'd love suggestions for
improvements.

The first patch can be applied without the other two.

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


[PATCH 1/3] count: Convert to new-style argument parsing

2012-01-10 Thread Austin Clements
---
 notmuch-count.c |   53 +
 1 files changed, 25 insertions(+), 28 deletions(-)

diff --git a/notmuch-count.c b/notmuch-count.c
index 20ce334..fb7401b 100644
--- a/notmuch-count.c
+++ b/notmuch-count.c
@@ -21,6 +21,11 @@
 
 #include notmuch-client.h
 
+typedef enum {
+OUTPUT_THREADS,
+OUTPUT_MESSAGES,
+} output_t;
+
 int
 notmuch_count_command (void *ctx, int argc, char *argv[])
 {
@@ -28,35 +33,23 @@ notmuch_count_command (void *ctx, int argc, char *argv[])
 notmuch_database_t *notmuch;
 notmuch_query_t *query;
 char *query_str;
-int i;
-notmuch_bool_t output_messages = TRUE;
+int opt_index;
+output_t output = OUTPUT_MESSAGES;
 
-argc--; argv++; /* skip subcommand argument */
+notmuch_opt_desc_t options[] = {
+   { NOTMUCH_OPT_KEYWORD, output, output, 'o',
+ (notmuch_keyword_t []){ { threads, OUTPUT_THREADS },
+ { messages, OUTPUT_MESSAGES },
+ { 0, 0 } } },
+   { 0, 0, 0, 0, 0 }
+};
 
-for (i = 0; i  argc  argv[i][0] == '-'; i++) {
-   if (strcmp (argv[i], --) == 0) {
-   i++;
-   break;
-   }
-   if (STRNCMP_LITERAL (argv[i], --output=) == 0) {
-   const char *opt = argv[i] + sizeof (--output=) - 1;
-   if (strcmp (opt, threads) == 0) {
-   output_messages = FALSE;
-   } else if (strcmp (opt, messages) == 0) {
-   output_messages = TRUE;
-   } else {
-   fprintf (stderr, Invalid value for --output: %s\n, opt);
-   return 1;
-   }
-   } else {
-   fprintf (stderr, Unrecognized option: %s\n, argv[i]);
-   return 1;
-   }
+opt_index = parse_arguments (argc, argv, options, 1);
+
+if (opt_index  0) {
+   return 1;
 }
 
-argc -= i;
-argv += i;
-
 config = notmuch_config_open (ctx, NULL, NULL);
 if (config == NULL)
return 1;
@@ -66,7 +59,7 @@ notmuch_count_command (void *ctx, int argc, char *argv[])
 if (notmuch == NULL)
return 1;
 
-query_str = query_string_from_args (ctx, argc, argv);
+query_str = query_string_from_args (ctx, argc-opt_index, argv+opt_index);
 if (query_str == NULL) {
fprintf (stderr, Out of memory.\n);
return 1;
@@ -82,10 +75,14 @@ notmuch_count_command (void *ctx, int argc, char *argv[])
return 1;
 }
 
-if (output_messages)
+switch (output) {
+case OUTPUT_MESSAGES:
printf (%u\n, notmuch_query_count_messages (query));
-else
+   break;
+case OUTPUT_THREADS:
printf (%u\n, notmuch_query_count_threads (query));
+   break;
+}
 
 notmuch_query_destroy (query);
 notmuch_database_close (notmuch);
-- 
1.7.7.3

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


[PATCH 2/3] lib: Add support for automatically excluding tags from queries

2012-01-10 Thread Austin Clements
This is useful for tags like deleted and spam that people
generally want to exclude from query results.  These exclusions will
be overridden if a tag is explicitly mentioned in a query.
---
 lib/notmuch.h |6 ++
 lib/query.cc  |   33 +
 2 files changed, 39 insertions(+), 0 deletions(-)

diff --git a/lib/notmuch.h b/lib/notmuch.h
index 9f23a10..0a3ae2b 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -457,6 +457,12 @@ notmuch_query_set_sort (notmuch_query_t *query, 
notmuch_sort_t sort);
 notmuch_sort_t
 notmuch_query_get_sort (notmuch_query_t *query);
 
+/* Add a tag that will be excluded by default from the query results.
+ * This exclusion will be overridden if this tag appears explicitly in
+ * the query. */
+void
+notmuch_query_add_tag_exclude (notmuch_query_t *query, const char *tag);
+
 /* Execute a query for threads, returning a notmuch_threads_t object
  * which can be used to iterate over the results. The returned threads
  * object is owned by the query and as such, will only be valid until
diff --git a/lib/query.cc b/lib/query.cc
index b6c0f12..716db1c 100644
--- a/lib/query.cc
+++ b/lib/query.cc
@@ -27,6 +27,7 @@ struct _notmuch_query {
 notmuch_database_t *notmuch;
 const char *query_string;
 notmuch_sort_t sort;
+notmuch_string_list_t *exclude_terms;
 };
 
 typedef struct _notmuch_mset_messages {
@@ -76,6 +77,8 @@ notmuch_query_create (notmuch_database_t *notmuch,
 
 query-sort = NOTMUCH_SORT_NEWEST_FIRST;
 
+query-exclude_terms = _notmuch_string_list_create (query);
+
 return query;
 }
 
@@ -97,6 +100,13 @@ notmuch_query_get_sort (notmuch_query_t *query)
 return query-sort;
 }
 
+void
+notmuch_query_add_tag_exclude (notmuch_query_t *query, const char *tag)
+{
+char *term = talloc_asprintf (query, %s%s, _find_prefix (tag), tag);
+_notmuch_string_list_append (query-exclude_terms, term);
+}
+
 /* We end up having to call the destructors explicitly because we had
  * to use placement new in order to initialize C++ objects within a
  * block that we allocated with talloc. So C++ is making talloc
@@ -112,6 +122,25 @@ _notmuch_messages_destructor (notmuch_mset_messages_t 
*messages)
 return 0;
 }
 
+static Xapian::Query
+_notmuch_exclude_tags (notmuch_query_t *query, Xapian::Query xquery)
+{
+Xapian::TermIterator end = xquery.get_terms_end ();
+
+for (notmuch_string_node_t *term = query-exclude_terms-head; term;
+term = term-next) {
+   Xapian::TermIterator it = xquery.get_terms_begin ();
+   for (; it != end; it++) {
+   if (*it == term-string)
+   break;
+   }
+   if (it == end)
+   xquery = Xapian::Query (Xapian::Query::OP_AND_NOT,
+   xquery, Xapian::Query (term-string));
+}
+return xquery;
+}
+
 notmuch_messages_t *
 notmuch_query_search_messages (notmuch_query_t *query)
 {
@@ -157,6 +186,8 @@ notmuch_query_search_messages (notmuch_query_t *query)
 mail_query, string_query);
}
 
+   final_query = _notmuch_exclude_tags (query, final_query);
+
enquire.set_weighting_scheme (Xapian::BoolWeight());
 
switch (query-sort) {
@@ -436,6 +467,8 @@ notmuch_query_count_messages (notmuch_query_t *query)
 mail_query, string_query);
}
 
+   final_query = _notmuch_exclude_tags (query, final_query);
+
enquire.set_weighting_scheme(Xapian::BoolWeight());
enquire.set_docid_order(Xapian::Enquire::ASCENDING);
 
-- 
1.7.7.3

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


Re: another attempt to add delete functionality in emacs

2012-01-10 Thread Jani Nikula
On Tue, 10 Jan 2012 19:12:16 -0800, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 On Tue, 10 Jan 2012 16:01:32 -0400, David Bremner da...@tethera.net wrote:
  Just thinking out loud here, but it does seem a bit unfortunate to me
  that it represents a pretty fundamental divergence between the CLI and
  the emacs interface. Mind you, I guess one could make the same argument
  about the libs versus the CLI. Lack of configuration information in the
  library (possibly among other reasons) makes this not too nice to
  support in the current library either.
 
 I think a consensus has formed that this functionality (automatically
 suppressing messages with certain tags from searches) is better left to
 the CLI, rather than implementing it just in the emacs UI.
 Unfortunately I'm not going to get to that any time soon.

I could have a go at it, but I can't make any promises about getting to
that any time soon either. So what if emacs ui goes head first and does
something that should be done in the CLI in a perfect world? If it's
added properly, it can be taken out if/when this pops up in the CLI.

Also, there already *is* filtering for all tags list. See
notmuch-hello-tag-list-make-query. How about having something like that
for saved searches? I know it's not the same as your original, but it's
middle ground...

 However, without that functionality, I really see no reason why we
 should be adding any built-in support for adding deleted tags in the
 emacs UI.  Without the CLI change, deleted tags aren't handled any
 differently than any other tag, so why should the default emacs UI care.
 If users want to bind keys to special tagging operations, they can do so
 for themselves [0].

In fact, deleted used to be special, but that was, err, deleted
because it had problems: 2c262042ac174d7bc96d6035ab9c88bd0abe7f35. If
that ever gets fixed, deleted would be special again.


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


Re: another attempt to add delete functionality in emacs

2012-01-10 Thread Austin Clements
Quoth Jani Nikula on Jan 11 at  7:16 am:
 On Tue, 10 Jan 2012 19:12:16 -0800, Jameson Graef Rollins 
 jroll...@finestructure.net wrote:
  On Tue, 10 Jan 2012 16:01:32 -0400, David Bremner da...@tethera.net wrote:
   Just thinking out loud here, but it does seem a bit unfortunate to me
   that it represents a pretty fundamental divergence between the CLI and
   the emacs interface. Mind you, I guess one could make the same argument
   about the libs versus the CLI. Lack of configuration information in the
   library (possibly among other reasons) makes this not too nice to
   support in the current library either.
  
  I think a consensus has formed that this functionality (automatically
  suppressing messages with certain tags from searches) is better left to
  the CLI, rather than implementing it just in the emacs UI.
  Unfortunately I'm not going to get to that any time soon.
 
 I could have a go at it, but I can't make any promises about getting to
 that any time soon either. So what if emacs ui goes head first and does
 something that should be done in the CLI in a perfect world? If it's
 added properly, it can be taken out if/when this pops up in the CLI.

Too late.  See id:1326258173-21163-1-git-send-email-amdra...@mit.edu
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH 2/4] emacs: repurpose notmuch-show-archive-thread-internal function for general thread tagging

2012-01-10 Thread Aaron Ecay
On Tue, 10 Jan 2012 18:56:29 -0800, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 Actually, the show-next argument was already part of the function.  I
 did not introduce it.  And it wasn't optional originally, so if we want
 to change that behavior we should probably do so in a separate patch.

Hrm.  I didn’t communicate as clearly as I could have – you are correct
that the show-next argument to the notmuch-show-archive-internal function
was pre-existing.  But notmuch-show-tag-thread-internal is a new function,
with potentially expanded usefulness to third-party code.  Thus I think
I’m in the clear to bikeshed about its calling convention.  :) It’s your
patch, though, so it’s your call if you feel that the optional goes best
in a new change.

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


Re: [PATCH 0/3] Automatic tag-based exclusion

2012-01-10 Thread Jameson Graef Rollins
On Wed, 11 Jan 2012 00:02:50 -0500, Austin Clements amdra...@mit.edu wrote:
 This implements essentially the same idea as Jamie's patch, but does
 it in the library/CLI and operates on the parsed query rather than
 using an ad hoc regexp.  Which tags are automatically excluded is set
 in the config file and defaults to deleted and spam.

Yay Austin!  Nice fast work!  That's really great.  Don't have time to
review right now, but asap.

I'll resend my emacs patches as soon as I can as well.

jamie.


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


Re: [PATCH 2/4] emacs: repurpose notmuch-show-archive-thread-internal function for general thread tagging

2012-01-10 Thread Jameson Graef Rollins
On Wed, 11 Jan 2012 00:53:35 -0500, Aaron Ecay aarone...@gmail.com wrote:
 On Tue, 10 Jan 2012 18:56:29 -0800, Jameson Graef Rollins 
 jroll...@finestructure.net wrote:
  Actually, the show-next argument was already part of the function.  I
  did not introduce it.  And it wasn't optional originally, so if we want
  to change that behavior we should probably do so in a separate patch.
 
 Hrm.  I didn’t communicate as clearly as I could have – you are correct
 that the show-next argument to the notmuch-show-archive-internal function
 was pre-existing.  But notmuch-show-tag-thread-internal is a new function,
 with potentially expanded usefulness to third-party code.  Thus I think
 I’m in the clear to bikeshed about its calling convention.  :) It’s your
 patch, though, so it’s your call if you feel that the optional goes best
 in a new change.

No, I see your point, Aaron.  I'll rework it to make it a little clean
and more flexible when I resend.  Thanks again.

jamie.


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