Re: [PATCH 2/4] emacs: repurpose notmuch-show-archive-thread-internal function for general thread tagging
On Wed, 11 Jan 2012 00:53:35 -0500, Aaron Ecay wrote: > On Tue, 10 Jan 2012 18:56:29 -0800, Jameson Graef Rollins > 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
[PATCH 2/4] emacs: repurpose notmuch-show-archive-thread-internal function for general thread tagging
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 &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. -- 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>
Re: [PATCH 0/3] Automatic tag-based exclusion
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. pgpOl8DO2iOnZ.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 0/3] Automatic tag-based exclusion
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.
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.
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.
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
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 2010 15:43:56 -, Notmuch T
[PATCH v3 3/4] emacs: bind 'r' to reply-to-sender and 'R' to reply-to-all
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
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 &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
[PATCH v3 1/4] cli: add support for replying just to the sender in "notmuch reply"
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 @@ add_recipients_for_
[PATCH v3 0/4] reply to sender
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
Re: [PATCH 2/4] emacs: repurpose notmuch-show-archive-thread-internal function for general thread tagging
On Tue, 10 Jan 2012 18:56:29 -0800, Jameson Graef Rollins 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: another attempt to add delete functionality in emacs
Quoth Jani Nikula on Jan 11 at 7:16 am: > On Tue, 10 Jan 2012 19:12:16 -0800, Jameson Graef Rollins > wrote: > > 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. > > 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: another attempt to add delete functionality in emacs
On Tue, 10 Jan 2012 19:12:16 -0800, Jameson Graef Rollins wrote: > 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. 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
[PATCH 3/3] search: Support automatic tag exclusions
This adds a "search" section to the config file and an
"auto_tag_exclusions" setting in that section. The search and count
commands pass tag tags from the configuration to the library.
---
notmuch-client.h |8
notmuch-config.c | 42 ++
notmuch-count.c |8
notmuch-search.c |8
test/search | 18 ++
5 files changed, 84 insertions(+), 0 deletions(-)
diff --git a/notmuch-client.h b/notmuch-client.h
index 517c010..62ede28 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -235,6 +235,14 @@ void
notmuch_config_set_maildir_synchronize_flags (notmuch_config_t *config,
notmuch_bool_t synchronize_flags);
+const char **
+notmuch_config_get_auto_exclude_tags (notmuch_config_t *config, size_t
*length);
+
+void
+notmuch_config_set_auto_exclude_tags (notmuch_config_t *config,
+ const char *list[],
+ size_t length);
+
int
notmuch_run_hook (const char *db_path, const char *hook);
diff --git a/notmuch-config.c b/notmuch-config.c
index d697138..6c3123b 100644
--- a/notmuch-config.c
+++ b/notmuch-config.c
@@ -84,6 +84,15 @@ static const char maildir_config_comment[] =
"\tand update tags, while the \"notmuch tag\" and \"notmuch restore\"\n"
"\tcommands will notice tag changes and update flags in filenames\n";
+static const char search_config_comment[] =
+" Search configuration\n"
+"\n"
+" The following option is supported here:\n"
+"\n"
+"\tauto_exclude_tags A ;-separated list of tags that will be\n"
+"\t excluded from queries by default. This can be overridden by
including\n"
+"\t these tags in a query.\n";
+
struct _notmuch_config {
char *filename;
GKeyFile *key_file;
@@ -96,6 +105,8 @@ struct _notmuch_config {
const char **new_tags;
size_t new_tags_length;
notmuch_bool_t maildir_synchronize_flags;
+const char **auto_exclude_tags;
+size_t auto_exclude_tags_length;
};
static int
@@ -221,6 +232,7 @@ notmuch_config_open (void *ctx,
int file_had_new_group;
int file_had_user_group;
int file_had_maildir_group;
+int file_had_search_group;
if (is_new_ret)
*is_new_ret = 0;
@@ -252,6 +264,8 @@ notmuch_config_open (void *ctx,
config->new_tags = NULL;
config->new_tags_length = 0;
config->maildir_synchronize_flags = TRUE;
+config->auto_exclude_tags = NULL;
+config->auto_exclude_tags_length = 0;
if (! g_key_file_load_from_file (config->key_file,
config->filename,
@@ -295,6 +309,7 @@ notmuch_config_open (void *ctx,
file_had_new_group = g_key_file_has_group (config->key_file, "new");
file_had_user_group = g_key_file_has_group (config->key_file, "user");
file_had_maildir_group = g_key_file_has_group (config->key_file,
"maildir");
+file_had_search_group = g_key_file_has_group (config->key_file, "search");
if (notmuch_config_get_database_path (config) == NULL) {
@@ -345,6 +360,11 @@ notmuch_config_open (void *ctx,
notmuch_config_set_new_tags (config, tags, 2);
}
+if (notmuch_config_get_auto_exclude_tags (config, &tmp) == NULL) {
+ const char *tags[] = { "deleted", "spam" };
+ notmuch_config_set_auto_exclude_tags (config, tags, 2);
+}
+
error = NULL;
config->maildir_synchronize_flags =
g_key_file_get_boolean (config->key_file,
@@ -387,6 +407,11 @@ notmuch_config_open (void *ctx,
maildir_config_comment, NULL);
}
+if (! file_had_search_group) {
+ g_key_file_set_comment (config->key_file, "search", NULL,
+ search_config_comment, NULL);
+}
+
if (is_new_ret)
*is_new_ret = is_new;
@@ -597,6 +622,23 @@ notmuch_config_set_new_tags (notmuch_config_t *config,
&(config->new_tags));
}
+const char **
+notmuch_config_get_auto_exclude_tags (notmuch_config_t *config, size_t *length)
+{
+return _config_get_list (config, "search", "auto_exclude_tags",
+&(config->auto_exclude_tags),
+&(config->auto_exclude_tags_length), length);
+}
+
+void
+notmuch_config_set_auto_exclude_tags (notmuch_config_t *config,
+ const char *list[],
+ size_t length)
+{
+_config_set_list (config, "search", "auto_exclude_tags", list, length,
+ &(config->auto_exclude_tags));
+}
+
/* Given a configuration item of the form . return the
* component group and key. If any error occurs, print a message on
* stderr and return 1. Otherwise, return 0.
diff --git a/notmuch-count.c b/notmuch-count.c
index fb7401b..494619f 100644
--- a/notmuch-count.c
+++ b/notmuch-count.c
@@ -35,6 +35,9 @@ notmuch_count_command (void *ctx, int
[PATCH 2/3] lib: Add support for automatically excluding tags from queries
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
[PATCH 1/3] count: Convert to new-style argument parsing
---
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 0/3] Automatic tag-based exclusion
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
Re: another attempt to add delete functionality in emacs
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))) pgpFUnDlSGwcj.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
another attempt to add delete functionality in emacs
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>
Re: [PATCH 2/4] emacs: repurpose notmuch-show-archive-thread-internal function for general thread tagging
On Mon, 09 Jan 2012 00:02:20 -0500, Aaron Ecay wrote:
> On Sun, 08 Jan 2012 18:49:56 -0800, Jameson Graef Rollins
> wrote:
> > On Sun, 08 Jan 2012 20:08:59 -0500, Aaron Ecay 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
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. pgpIJloiuCNqu.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2/4] emacs: repurpose notmuch-show-archive-thread-internal function for general thread tagging
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 &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.
-- 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
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.
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.
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
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.
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>
Re: [PATCH] emacs: Improve `notmuch-hello' display on ttys.
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@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: [PATCH v2] emacs: Cycle through notmuch buffers rather than jumping to the last.
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. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Improve `notmuch-hello' display on ttys.
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@notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: another attempt to add delete functionality in emacs
On Tue, 10 Jan 2012 07:47:23 +, David Edmondson wrote: > 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. [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
[PATCH v3 4/4] test: add tests for "notmuch reply" --reply-to=sender
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_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
+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_su...@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_su...@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 2010 15:43:56 -, Notmuc
[PATCH v3 3/4] emacs: bind 'r' to reply-to-sender and 'R' to reply-to-all
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 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v3 2/4] emacs: add support for replying just to the sender
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 &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 1/4] cli: add support for replying just to the sender in "notmuch reply"
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@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 @@ add_recipients_f
[PATCH v3 0/4] reply to sender
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@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 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2/3 v2] test: Add tests for `notmuch-show-clean-address'.
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.
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.
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.
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
Re: [PATCH v2] emacs: Cycle through notmuch buffers rather than jumping to the last.
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? pgpW7uPCmz2l5.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.
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.) pgplkDC2XarEk.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2/2] notmuch-reply.c: uncrustify
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)
- {
+ strcmp (disposition->di
[PATCH 1/2] uncrustify.cfg: initial support for notmuch coding style
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 # align stuff in a stru
No subject
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.
Re: [PATCH] emacs: Improve `notmuch-hello' display on ttys.
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.) ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
change to default archive/delete key bindings
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>
Re: [PATCH] emacs: Improve `notmuch-hello' display on ttys.
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. pgpNvEQrnYjvQ.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
another attempt to add delete functionality in emacs
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
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>
Re: [PATCH] emacs: Improve `notmuch-hello' display on ttys.
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
[PATCH 4/4] emacs: Use the new JSON reply format.
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
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'.
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.
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
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
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
Re: change to default archive/delete key bindings
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 :-/ pgpZI9J5wINnJ.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [ANNOUNCE] mutt with notmuch support
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: [PATCH] man: add missing SEE ALSO header to notmuch reply man page
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(-) +1 /Xavier ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2/2] notmuch-reply.c: uncrustify
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)
- {
+ strcmp (disposition
[PATCH 1/2] uncrustify.cfg: initial support for notmuch coding style
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 # align stuff in a stru
[no subject]
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
Re: [PATCH 2/3 v2] test: Add tests for `notmuch-show-clean-address'.
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, - . pgpKuyfK3XwWl.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Properly handle short writes in sigint handlers
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 ___ 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'.
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 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Mark the quoted region during reply.
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 ___ 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
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 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [RFC PATCH 3/9] lib: fix messages.c build warn
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 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs: Improve `notmuch-hello' display on ttys.
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: another attempt to add delete functionality in emacs
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. pgp1XKKtLJuRB.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/4 v2] emacs: add show-mode functions to archive/delete only current message
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.
pgpF5RhFNS8CD.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 4/4] emacs: Use the new JSON reply format.
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'). pgpB2tf7cE23L.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Distributed Notmuch
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. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] NEWS: add news entry for notmuch reply uninitialized variable bugfix
On Mon, 9 Jan 2012 11:49:56 +, Jani Nikula wrote: > --- > > This is against release branch. > --- Pushed to release. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 4/4] emacs: Use the new JSON reply format.
On Sun, Jan 8, 2012 at 18:27, Aaron Ecay 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 v2 0/6] reply to sender
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: Python bindings for adoption
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
Distributed Notmuch
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.
