Goto command for existing search windows

[Jameson Graef Rollins]

On Thu, Mar 29 2012, Jani Nikula  wrote:
> Hi, I believe Mark's point was just switching to the buffer if it
> exists, *without* refreshing or doing the query, and only doing regular
> notmuch-search if a buffer doesn't exist yet.

I understand, but searches are so fast, particularly for searches that
you're doing frequently enough to map to a key binding, that I really
doubt it would ever be an issue.  It's certainly not for me.

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/20120329/e92338d1/attachment.pgp>

[PATCH v2]: contrib/notmuch-mutt

[Stefano Zacchiroli]

On Sun, Mar 25, 2012 at 10:13:38AM -0300, David Bremner wrote:
> In the mean time, we at least have a contrib directory, and I think
> mutt-notmuch would be welcome there. Could you (or somebody) make a
> reasonable size patch series that adds it to contrib/mutt-notmuch
> against current master. The patch series should be sent to the
> upstream mailing list notmuch at notmuchmail.org for review.
> 
> On the debian side your patch series could also include the necessary
> changes to make a new binary package.
> 
> Notmuch itself is already GPL3+ so no hassles there (for once).

Here is an updated set of patches, which I consider final for inclusion
of notmuch-mutt as part of notmuch contrib/.  AFAICT I've implemented
all changes that have been requested either on this list or in private
mail to me: renaming, Debian packaging, XDG userdir support, shell
quoting in all notmuch calls. TTBOMK, no further changes have been
requested.

Can some kind soul "git am" the attached patches to notmuch Git repo?

If OTOH you have further request for changes, please let me know. I'll
be happy to act on them.

TIA,
Cheers.
-- 
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Ma?tre de conf?rences   ..   http://upsilon.cc/zack   ..   . . o
Debian Project Leader...   @zack on identi.ca   ...o o o
? the first rule of tautology club is the first rule of tautology club ?
-- next part --
A non-text attachment was scrubbed...
Name: 0001-contrib-new-mutt-notmuch-utility-for-Mutt-integratio.patch
Type: text/x-diff
Size: 11521 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120329/38fbb944/attachment.patch>
-- next part --
A non-text attachment was scrubbed...
Name: 0002-debian-packaging-new-binary-package-notmuch-mutt.patch
Type: text/x-diff
Size: 3200 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120329/38fbb944/attachment-0001.patch>
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120329/38fbb944/attachment.pgp>

[PATCH] vim: fix regex after "notmuch show" output change

[Jakob]

The new field "excluded" was added to the output and made this regex fail.
---
 vim/plugin/notmuch.vim |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/vim/plugin/notmuch.vim b/vim/plugin/notmuch.vim
index 21985c7..8f27fb9 100644
--- a/vim/plugin/notmuch.vim
+++ b/vim/plugin/notmuch.vim
@@ -48,7 +48,7 @@ let s:notmuch_defaults = {
 \ 'g:notmuch_show_part_end_regexp':  'part}'  
 ,
 \ 'g:notmuch_show_marker_regexp':'
\\(message\\|header\\|body\\|attachment\\|part\\)[{}].*$',
 \
-\ 'g:notmuch_show_message_parse_regexp': '\(id:[^ ]*\) 
depth:\([0-9]*\) match:\([0-9]*\) filename:\(.*\)$',
+\ 'g:notmuch_show_message_parse_regexp': '\(id:[^ ]*\) 
depth:\([0-9]*\) match:\([0-9]*\) excluded:\([0-9]*\) filename:\(.*\)$',
 \ 'g:notmuch_show_tags_regexp':  '(\([^)]*\))$'
   ,
 \
 \ 'g:notmuch_show_signature_regexp': '^\(-- \?\|_\+\)$'
   ,
@@ -870,7 +870,8 @@ function! s:NM_cmd_show_parse(inlines)
 let msg['id'] = m[1]
 let msg['depth'] = m[2]
 let msg['match'] = m[3]
-let msg['filename'] = m[4]
+let msg['excluded'] = m[4]
+let msg['filename'] = m[5]
 endif

 let in_message = 1
-- 
1.7.9.1

[PATCH] vim: fix regex after "notmuch show" output change

[Jakob]

On Sun, 25 Mar 2012 22:42:53 +0300, Tomi Ollila  wrote:
> I meant about the syntax: \([[0-9]*\) i.e. 2 opening [[:s

Good eye!  The regex worked, but I guess I was matching digits /and/
open-brackets.  I'll fix that.

Thanks,
Jakob

notmuch and Debian's BTS/PTS [was: Re: [Joerg Jaspert] Bug#666027: notmuch: get a quiet option]

[Andrei POPESCU]

On Jo, 29 mar 12, 07:34:15, David Bremner wrote:
> We could give it a try and see how it works.  I suspect it needs the
> assistance of one of the notmuch list moderators (which I understand we
> have delegates for as of a few days ago) to get the BTS able to send to
> the list. Any Debian savvy volunteers to sort this out?

If there's something I can do...

Does it make sense to subscribe the list to PTS[1] instead? I'd say the 
bts, bts-control, buildd, default and contact keywords[2] make sense.

[1] Package Tracking System
[2] 
http://www.debian.org/doc/manuals/developers-reference/resources.html#pkg-tracking-system

Kind regards,
Andrei
-- 
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120329/47957b1e/attachment.pgp>

[BUG/PATCH v2 0/2] emacs: Yesterday's bugfixes

[Austin Clements]

On Thu, 29 Mar 2012, Adam Wolfe Gordon  wrote:
> This is last night's two bugfixes [1] [2], combined into one series since they
> won't both apply cleanly separately.
>
> The only change to the fix for emacs 23.2 is the name of the function
> notmuch-plist-to-alist is now notmuch-header-plist-to-alist, which more
> accurately reflects what it does.
>
> The References fix has been changed to use the existing formatter for
> References instead of hard-coding message-shorten-references, and to keep the
> headers in the same order they're in by default.
>
> [1] id:"1332943338-9708-1-git-send-email-awg+notmuch at xvx.ca"
> [2] id:"1332996818-15700-1-git-send-email-awg+notmuch at xvx.ca"
>
> Adam Wolfe Gordon (2):
>   emacs: Fix header problem in reply for emacs 23.2
>   emacs: Fix the References header in reply
>
>  emacs/notmuch-lib.el |7 +--
>  emacs/notmuch-mua.el |   38 ++
>  2 files changed, 35 insertions(+), 10 deletions(-)

LGTM.

To keep everything in one thread, Jamie also signed off this patch in
id:"87obrf48ci.fsf at servo.finestructure.net".

[BUG/PATCH] emacs: Fix header problem in reply for emacs 23.2

[Jani Nikula]

On Wed, 28 Mar 2012 08:02:18 -0600, Adam Wolfe Gordon  
wrote:
> The new reply code used strings instead of symbols for header names,
> which message-mail is OK with on emacs 23.3, but not 23.2. The symptom
> is that on 23.2 (and presumably on earlier versions) the reply message
> would end up with two of some headers.
> 
> This fixes the problem by converting the header names to symbols of
> the type message.el usually expects before passing the headers to
> message-mail.

The patch depends on some set of the other reply fixes (*), so I applied
this on top of them. All tests pass with emacs 23.2.

Unfortunately, the emacs UI fails with "Symbol's function definition is
void: remove-if" when trying to reply. After a manual (require 'cl) the
UI seems to otherwise work as expected. This is probably unrelated to
this particular patch, but why is it a (eval-when-compile (require 'cl))
and not (require 'cl) in notmuch-mua.el?


BR,
Jani.


(*)
id:"1332941635-21019-2-git-send-email-awg+notmuch at xvx.ca"
id:"1332941635-21019-3-git-send-email-awg+notmuch at xvx.ca"
id:"1332996818-15700-1-git-send-email-awg+notmuch at xvx.ca"

> ---
>  emacs/notmuch-lib.el |5 -
>  emacs/notmuch-mua.el |   10 +-
>  2 files changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
> index c146748..af46611 100644
> --- a/emacs/notmuch-lib.el
> +++ b/emacs/notmuch-lib.el
> @@ -232,9 +232,12 @@ the given type."
>(or (plist-get part :content)
>(notmuch-get-bodypart-internal (concat "id:" (plist-get msg :id)) nth 
> process-crypto)))
>  
> +;; Converts a plist of headers to an alist of headers. The input plist should
> +;; have symbols of the form :Header as keys, and the resulting alist will 
> have
> +;; symbols of the form 'Header as keys.
>  (defun notmuch-plist-to-alist (plist)
>(loop for (key value . rest) on plist by #'cddr
> - collect (cons (substring (symbol-name key) 1) value)))
> + collect (cons (intern (substring (symbol-name key) 1)) value)))
>  
>  ;; Compatibility functions for versions of emacs before emacs 23.
>  ;;
> diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
> index 9805d79..24918d3 100644
> --- a/emacs/notmuch-mua.el
> +++ b/emacs/notmuch-mua.el
> @@ -185,11 +185,11 @@ OTHER-ARGS are passed through to `message-mail'."
>(when notmuch-mua-user-agent-function
>  (let ((user-agent (funcall notmuch-mua-user-agent-function)))
>(when (not (string= "" user-agent))
> - (push (cons "User-Agent" user-agent) other-headers
> + (push (cons 'User-Agent user-agent) other-headers
>  
> -  (unless (assoc "From" other-headers)
> -(push (cons "From" (concat
> - (notmuch-user-name) " <" (notmuch-user-primary-email) 
> ">")) other-headers))
> +  (unless (assq 'From other-headers)
> +(push (cons 'From (concat
> +(notmuch-user-name) " <" (notmuch-user-primary-email) 
> ">")) other-headers))
>  
>(apply #'message-mail to subject other-headers other-args)
>(message-sort-headers)
> @@ -250,7 +250,7 @@ the From: address first."
>(interactive "P")
>(let ((other-headers
>(when (or prompt-for-sender notmuch-always-prompt-for-sender)
> -(list (cons "From" (notmuch-mua-prompt-for-sender))
> +(list (cons 'From (notmuch-mua-prompt-for-sender))
>  (notmuch-mua-mail nil nil other-headers)))
>  
>  (defun notmuch-mua-new-forward-message ( prompt-for-sender)
> -- 
> 1.7.5.4
> 

Goto command for existing search windows

[Jameson Graef Rollins]

On Thu, Mar 29 2012, Mark Anderson  wrote:
> On Tue, 27 Mar 2012 14:24:36 -0600, Mark Anderson  
> wrote:
>> I was looking for a function which would find a buffer based on one of
>> my saved searches, and perform the search if it didn't exist.
>> 
>> I've gotten it a bit closer, if I perform the search that matches a
>> saved search, then this routine will find it because of the magic in
>> notmuch-search-buffer-title, but perhaps someone else feels up to
>> searching through the saved searches directly?

Hey, Mark.  I think you can be a little simpler.  The title for search
buffers is based on the search, so a buffer will always be reused for an
identical search.  You don't need to do any fancy buffer searching.  For
instance, the following works perfectly for me, and I believe produces
the same results as your technique:

(defun jnotmuch-inbox ()
  "Search: inbox"
  (interactive)
  (notmuch-search "tag:inbox" t))
(define-key notmuch-hello-mode-map "2" 'jnotmuch-inbox)
(define-key notmuch-search-mode-map "2" 'jnotmuch-inbox)
(define-key notmuch-show-mode-map "2" 'jnotmuch-inbox)

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/20120329/1712a7c6/attachment.pgp>

[BUG/PATCH v2 0/2] emacs: Yesterday's bugfixes

[Jameson Graef Rollins]

On Thu, Mar 29 2012, Austin Clements  wrote:
> To keep everything in one thread, Jamie also signed off this patch in
> id:"87obrf48ci.fsf at servo.finestructure.net".

Doh.  Sorry about that.  Yes, I've tested this new version and it works
and LGTM.

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/20120329/3e5737cc/attachment.pgp>

[BUG/PATCH v2] emacs: Fix the References header in reply

[Adam Wolfe Gordon]

Hi Jamie,

On Thu, Mar 29, 2012 at 11:14, Jameson Graef Rollins
 wrote:
> I just tested this patch and it does seem to fix the issue. ?However, a
> side effect seems to be that the References header is now appearing as
> the first header in the reply buffer, rather than the last, as it used
> to. ?I suppose this is merely aesthetic, but I did prefer the ordering
> as it was before. ?Is there a way to tweak the
> message-header-format-alist so that the References header appears last
> again?

That's actually fixed by the new version [1]. As Austin mentioned in
his review, the order of message-header-format-alist determines the
order of the headers.

[1] id:"1333038410-17927-3-git-send-email-awg+notmuch at xvx.ca"

> Given the various things that are being affected by this, it would
> probably be good to add a test for this as well.

Yeah, I think a test would be good. This isn't caught by the existing
emacs reply tests because the References and User-Agent headers are
hidden by default. Is there a function in emacs to tell message-mode
to show all the headers, so we can verify that they're correct?

-- 
Adam

[BUG/PATCH v2] emacs: Fix the References header in reply

[Jameson Graef Rollins]

On Thu, Mar 29 2012, Adam Wolfe Gordon <awg+notmuch at xvx.ca> wrote:
> That's actually fixed by the new version [1]. As Austin mentioned in
> his review, the order of message-header-format-alist determines the
> order of the headers.
>
> [1] id:"1333038410-17927-3-git-send-email-awg+notmuch at xvx.ca"

Awesome!  Thanks so much Adam!  I just tested it and it works great:
solves the issue and the headers are in a nice order.  Thanks again for
the quick fix.

I see one tiny whitespace error, but overall the rest of the patches
looks great, so I say it's not worth resubmitting.  LGTM.

>> Given the various things that are being affected by this, it would
>> probably be good to add a test for this as well.
>
> Yeah, I think a test would be good. This isn't caught by the existing
> emacs reply tests because the References and User-Agent headers are
> hidden by default. Is there a function in emacs to tell message-mode
> to show all the headers, so we can verify that they're correct?

There must be, since I am seeing the In-Reply-To and References headers,
but I can't find what customization variable it is at the moment.  It
looks like I am using message-required-headers:

(message-required-headers ((optional . References) From)

But looking through the plethora of message-mode options, I think there
is probably multiple ways to set this.

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/20120329/a9c5939e/attachment.pgp>

[BUG/PATCH v2 2/2] emacs: Fix the References header in reply

[Adam Wolfe Gordon]

In the new reply code, the References header gets inserted by
message.el using a function called message-shorten-references. Unlike
all the other header-inserting functions, it doesn't put a newline
after the header, causing the next header to end up on the same
line. In our case, this header happened to be User-Agent, so it's hard
to notice. This is probably a bug in message.el, but we need to work
around it.

This fixes the problem by wrapping message-shorten-references in a
function that inserts a newline after if necessary. This should
protect against the message.el bug being fixed in the future.
---
 emacs/notmuch-mua.el |   28 +---
 1 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index cfa3d61..9f279d9 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -90,6 +90,15 @@ list."
else if (notmuch-match-content-type (plist-get part :content-type) 
"text/*")
  collect part))

+;; There is a bug in emacs 23's message.el that results in a newline
+;; not being inserted after the References header, so the next header
+;; is concatenated to the end of it. This function fixes the problem,
+;; while guarding against the possibility that some current or future
+;; version of emacs has the bug fixed.
+(defun notmuch-mua-insert-references (original-func header references)
+  (funcall original-func header references)
+  (unless (bolp) (insert "\n")))
+
 (defun notmuch-mua-reply (query-string  sender reply-all)
   (let ((args '("reply" "--format=json"))
reply
@@ -125,9 +134,22 @@ list."
  ;; Overlay the composition window on that being used to read
  ;; the original message.
  ((same-window-regexps '("\\*mail .*")))
-   (notmuch-mua-mail (plist-get reply-headers :To)
- (plist-get reply-headers :Subject)
- (notmuch-headers-plist-to-alist reply-headers)))
+
+   ;; We modify message-header-format-alist to get around a bug in 
message.el.
+   ;; See the comment above on notmuch-mua-insert-references.
+   (let ((message-header-format-alist
+  (loop for pair in message-header-format-alist
+if (eq (car pair) 'References)
+collect (cons 'References 
+  (apply-partially
+   'notmuch-mua-insert-references
+   (cdr pair)))
+else
+collect pair)))
+ (notmuch-mua-mail (plist-get reply-headers :To)
+   (plist-get reply-headers :Subject)
+   (notmuch-headers-plist-to-alist reply-headers
+
   ;; Insert the message body - but put it in front of the signature
   ;; if one is present
   (goto-char (point-max))
-- 
1.7.5.4

[BUG/PATCH v2 1/2] emacs: Fix header problem in reply for emacs 23.2

[Adam Wolfe Gordon]

The new reply code used strings instead of symbols for header names,
which message-mail is OK with on emacs 23.3, but not 23.2. The symptom
is that on 23.2 (and presumably on earlier versions) the reply message
would end up with two of some headers.

This fixes the problem by converting the header names to symbols of
the type message.el usually expects before passing the headers to
message-mail.
---
 emacs/notmuch-lib.el |7 +--
 emacs/notmuch-mua.el |   12 ++--
 2 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
index c146748..0effe24 100644
--- a/emacs/notmuch-lib.el
+++ b/emacs/notmuch-lib.el
@@ -232,9 +232,12 @@ the given type."
   (or (plist-get part :content)
   (notmuch-get-bodypart-internal (concat "id:" (plist-get msg :id)) nth 
process-crypto)))

-(defun notmuch-plist-to-alist (plist)
+;; Converts a plist of headers to an alist of headers. The input plist should
+;; have symbols of the form :Header as keys, and the resulting alist will have
+;; symbols of the form 'Header as keys.
+(defun notmuch-headers-plist-to-alist (plist)
   (loop for (key value . rest) on plist by #'cddr
-   collect (cons (substring (symbol-name key) 1) value)))
+   collect (cons (intern (substring (symbol-name key) 1)) value)))

 ;; Compatibility functions for versions of emacs before emacs 23.
 ;;
diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index 9805d79..cfa3d61 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -127,7 +127,7 @@ list."
  ((same-window-regexps '("\\*mail .*")))
(notmuch-mua-mail (plist-get reply-headers :To)
  (plist-get reply-headers :Subject)
- (notmuch-plist-to-alist reply-headers)))
+ (notmuch-headers-plist-to-alist reply-headers)))
   ;; Insert the message body - but put it in front of the signature
   ;; if one is present
   (goto-char (point-max))
@@ -185,11 +185,11 @@ OTHER-ARGS are passed through to `message-mail'."
   (when notmuch-mua-user-agent-function
 (let ((user-agent (funcall notmuch-mua-user-agent-function)))
   (when (not (string= "" user-agent))
-   (push (cons "User-Agent" user-agent) other-headers
+   (push (cons 'User-Agent user-agent) other-headers

-  (unless (assoc "From" other-headers)
-(push (cons "From" (concat
-   (notmuch-user-name) " <" (notmuch-user-primary-email) 
">")) other-headers))
+  (unless (assq 'From other-headers)
+(push (cons 'From (concat
+  (notmuch-user-name) " <" (notmuch-user-primary-email) 
">")) other-headers))

   (apply #'message-mail to subject other-headers other-args)
   (message-sort-headers)
@@ -250,7 +250,7 @@ the From: address first."
   (interactive "P")
   (let ((other-headers
 (when (or prompt-for-sender notmuch-always-prompt-for-sender)
-  (list (cons "From" (notmuch-mua-prompt-for-sender))
+  (list (cons 'From (notmuch-mua-prompt-for-sender))
 (notmuch-mua-mail nil nil other-headers)))

 (defun notmuch-mua-new-forward-message ( prompt-for-sender)
-- 
1.7.5.4

[BUG/PATCH v2 0/2] emacs: Yesterday's bugfixes

[Adam Wolfe Gordon]

This is last night's two bugfixes [1] [2], combined into one series since they
won't both apply cleanly separately.

The only change to the fix for emacs 23.2 is the name of the function
notmuch-plist-to-alist is now notmuch-header-plist-to-alist, which more
accurately reflects what it does.

The References fix has been changed to use the existing formatter for
References instead of hard-coding message-shorten-references, and to keep the
headers in the same order they're in by default.

[1] id:"1332943338-9708-1-git-send-email-awg+notmuch at xvx.ca"
[2] id:"1332996818-15700-1-git-send-email-awg+notmuch at xvx.ca"

Adam Wolfe Gordon (2):
  emacs: Fix header problem in reply for emacs 23.2
  emacs: Fix the References header in reply

 emacs/notmuch-lib.el |7 +--
 emacs/notmuch-mua.el |   38 ++
 2 files changed, 35 insertions(+), 10 deletions(-)

-- 
1.7.5.4

[BUG/PATCH v2] emacs: Fix the References header in reply

[Jameson Graef Rollins]

On Wed, Mar 28 2012, Adam Wolfe Gordon <awg+notmuch at xvx.ca> wrote:
> In the new reply code, the References header gets inserted by
> message.el using a function called message-shorten-references. Unlike
> all the other header-inserting functions, it doesn't put a newline
> after the header, causing the next header to end up on the same
> line. In our case, this header happened to be User-Agent, so it's hard
> to notice. This is probably a bug in message.el, but we need to work
> around it.
>
> This fixes the problem by wrapping message-shorten-references in a
> function that inserts a newline after if necessary. This should
> protect against the message.el bug being fixed in the future.

Hey, Adam.  Thanks so much for working on this.

I just tested this patch and it does seem to fix the issue.  However, a
side effect seems to be that the References header is now appearing as
the first header in the reply buffer, rather than the last, as it used
to.  I suppose this is merely aesthetic, but I did prefer the ordering
as it was before.  Is there a way to tweak the
message-header-format-alist so that the References header appears last
again?

Given the various things that are being affected by this, it would
probably be good to add a test for this 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/20120329/cfe091b1/attachment.pgp>

Goto command for existing search windows

[Mark Anderson]

On Tue, 27 Mar 2012 14:24:36 -0600, Mark Anderson  
wrote:
> I was looking for a function which would find a buffer based on one of
> my saved searches, and perform the search if it didn't exist.
> 
> I've gotten it a bit closer, if I perform the search that matches a
> saved search, then this routine will find it because of the magic in
> notmuch-search-buffer-title, but perhaps someone else feels up to
> searching through the saved searches directly?
> 
> 
> 
> (defun notmuch-goto-or-search ( query)
>   "Find a notmuch-search buffer with the given query, or run 
> \"notmuch search\" with the given `query' and display results.
> 
> If `query' is nil, it is read interactively from the minibuffer."
>   (interactive)
>   (if (null query)
>   (setq query (notmuch-read-query "Notmuch goto-or-search: ")))
>   (let ((buffer-name (notmuch-search-buffer-title query)))
> (setq buf (get-buffer buffer-name)))
>   
> (if (not buf)
> (notmuch-search query)
>   (switch-to-buffer buf)
>   )))

I have a slightly better-for-me version now:

(defun notmuch-goto-or-search ( query)
  "Find a notmuch saved-search query with the given name, or a
search with the given query, switching to an existing buffer
without changes in preference to automatically refreshing or
creating the search buffer.

If `query' is nil, it is read interactively from the minibuffer."
  (interactive)
  (if (null query)
  (setq query (notmuch-read-query "Notmuch goto-or-search: ")))
  (let ((saved-search-tuple (assoc query notmuch-saved-searches)))
(setq expanded-query
  (if (null saved-search-tuple)
  query
(cdr saved-search-tuple
  (let ((buffer-name (notmuch-search-buffer-title expanded-query)))
(setq buf (get-buffer buffer-name)))
(if (not buf)
(notmuch-search expanded-query)
  (switch-to-buffer buf)
  ))

This does search the saved searches to see if you entered a saved search
name.  With this I don't have to duplicate my query for saved searches
in key bindings.

(global-set-key [f8] (lambda () (interactive) (notmuch-goto-or-search "Inbox")))
(global-set-key [f9] (lambda () (interactive) (notmuch-goto-or-search "INBOX")))
(global-set-key [f10] (lambda () (interactive) (notmuch-goto-or-search "todo")))


> I then use it something like this:
> 
> (global-set-key [C-f1] (lambda () (interactive) (notmuch-goto-or-search 
> "tag:inbox and tag:unread and not tag:deleted")))
> (global-set-key [C-f2] (lambda () (interactive) (notmuch-goto-or-search 
> "tag:inbox and not tag:deleted")))
> (global-set-key [C-f3] 'notmuch)
> (global-set-key [C-f6] (lambda () (interactive) (notmuch-goto-or-search 
> "tag:todo and not tag:deleted")))
> 
> It would be better if I could use my Inbox, INBOX and todo names for the
> saved searches, but how to do that without breaking generality of
> searching the body of the email?  Do I have to define my own ss: (saved
> search) prefix or something, as I believe some others have?
> 
> This is what I'm willing to do today, and it works for me, I could patch
> notmuch.el, but I wondered about answering the other questions.
> 
> Also, some elisp master could hint about how to make the binding not so
> ugly. ;)
> 
> Another appreciated elisp hint would be how to get the buf variable to
> go inside the let, I keep getting complaints about buffer-name not being
> defined, thus the "ugly" setq, which works.
> 
> Enjoy,
> 
> -Mark

[PATCH v3 0/4] cli: notmuch tag/restore refactoring

[Austin Clements]

Quoth Jani Nikula on Mar 27 at 12:04 am:
> v3 of id:"cover.1332702915.git.jani at nikula.org" with the following
> mostly non-functional changes:
> 
>  - add test for the current tagging behaviour in patch 1, and change the
>test in patch 2 when the behaviour is changed
>  - handle the no tag changes case in _optimize_tag_query() in patch 2
>  - add braces around the "tag_ops[tag_ops_count].remove = (argv[i][0] == 
> '-');"
>assignment
>  - document the tag_query() function a bit in patch 3
>  - make tag_message() static in patch 4
> 
> BR,
> Jani.

LGTM.

[BUG/PATCH] emacs: Fix header problem in reply for emacs 23.2

[Austin Clements]

Quoth Adam Wolfe Gordon on Mar 28 at  8:02 am:
> The new reply code used strings instead of symbols for header names,
> which message-mail is OK with on emacs 23.3, but not 23.2. The symptom
> is that on 23.2 (and presumably on earlier versions) the reply message
> would end up with two of some headers.
> 
> This fixes the problem by converting the header names to symbols of
> the type message.el usually expects before passing the headers to
> message-mail.
> ---
>  emacs/notmuch-lib.el |5 -
>  emacs/notmuch-mua.el |   10 +-
>  2 files changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
> index c146748..af46611 100644
> --- a/emacs/notmuch-lib.el
> +++ b/emacs/notmuch-lib.el
> @@ -232,9 +232,12 @@ the given type."
>(or (plist-get part :content)
>(notmuch-get-bodypart-internal (concat "id:" (plist-get msg :id)) nth 
> process-crypto)))
>  
> +;; Converts a plist of headers to an alist of headers. The input plist should
> +;; have symbols of the form :Header as keys, and the resulting alist will 
> have
> +;; symbols of the form 'Header as keys.
>  (defun notmuch-plist-to-alist (plist)

This name isn't really appropriate now.
notmuch-plist-to-headers-list?  notmuch-headers-plist-to-alist?

Otherwise LGTM, though I don't run such ancient versions of Emacs, so
I can't verify that it fixes the problem.

>(loop for (key value . rest) on plist by #'cddr
> - collect (cons (substring (symbol-name key) 1) value)))
> + collect (cons (intern (substring (symbol-name key) 1)) value)))
>  
>  ;; Compatibility functions for versions of emacs before emacs 23.
>  ;;
> diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
> index 9805d79..24918d3 100644
> --- a/emacs/notmuch-mua.el
> +++ b/emacs/notmuch-mua.el
> @@ -185,11 +185,11 @@ OTHER-ARGS are passed through to `message-mail'."
>(when notmuch-mua-user-agent-function
>  (let ((user-agent (funcall notmuch-mua-user-agent-function)))
>(when (not (string= "" user-agent))
> - (push (cons "User-Agent" user-agent) other-headers
> + (push (cons 'User-Agent user-agent) other-headers
>  
> -  (unless (assoc "From" other-headers)
> -(push (cons "From" (concat
> - (notmuch-user-name) " <" (notmuch-user-primary-email) 
> ">")) other-headers))
> +  (unless (assq 'From other-headers)
> +(push (cons 'From (concat
> +(notmuch-user-name) " <" (notmuch-user-primary-email) 
> ">")) other-headers))
>  
>(apply #'message-mail to subject other-headers other-args)
>(message-sort-headers)
> @@ -250,7 +250,7 @@ the From: address first."
>(interactive "P")
>(let ((other-headers
>(when (or prompt-for-sender notmuch-always-prompt-for-sender)
> -(list (cons "From" (notmuch-mua-prompt-for-sender))
> +(list (cons 'From (notmuch-mua-prompt-for-sender))
>  (notmuch-mua-mail nil nil other-headers)))
>  
>  (defun notmuch-mua-new-forward-message ( prompt-for-sender)

[BUG/PATCH v2] emacs: Fix the References header in reply

[Austin Clements]

Quoth Adam Wolfe Gordon on Mar 28 at 10:53 pm:
> In the new reply code, the References header gets inserted by
> message.el using a function called message-shorten-references. Unlike
> all the other header-inserting functions, it doesn't put a newline
> after the header, causing the next header to end up on the same
> line. In our case, this header happened to be User-Agent, so it's hard
> to notice. This is probably a bug in message.el, but we need to work
> around it.
> 
> This fixes the problem by wrapping message-shorten-references in a
> function that inserts a newline after if necessary. This should
> protect against the message.el bug being fixed in the future.
> ---

Ugh.  message-mode is such a rat's nest.  I dug through this and it
looks like message-shorten-references really is at fault here.

I'm sure you already tracked this down, but for others who may be
interested, ultimately, the headers are inserted by
mail-header-format, which calls formatter functions or, if there is no
formatter, mail-header-format-function.  mail-header-format-function
inserts a newline after the header and, indeed, mail-header-format
does not insert anything between headers, so this is clearly up to the
formatter.  message-shorten-references, however, inserts its header by
calling message-insert-header, which looks remarkably like
mail-header-format-function, minus the newline.  Ironically,
message-shorten-references appears to be the only formatter configured
by default.

> This version adds the local variables to suppress 'cl warings, per
> id:"1332995623-9055-1-git-send-email-amdragon at mit.edu".
> 
>  emacs/notmuch-mua.el |   26 +++---
>  1 files changed, 23 insertions(+), 3 deletions(-)
> 
> diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
> index 24918d3..0d3fcd3 100644
> --- a/emacs/notmuch-mua.el
> +++ b/emacs/notmuch-mua.el
> @@ -90,6 +90,15 @@ list."
>   else if (notmuch-match-content-type (plist-get part :content-type) 
> "text/*")
> collect part))
>  
> +;; There is a bug in emacs 23's message.el that results in a newline
> +;; not being inserted after the References header, so the next header
> +;; is concatenated to the end of it. This function fixes the problem,
> +;; while guarding against the possibility that some current or future
> +;; version of emacs has the bug fixed.
> +(defun notmuch-mua-insert-references (header references)
> +  (message-shorten-references header references)
> +  (unless (bolp) (insert "\n")))
> +

Would it be safer to call whatever was associated with References in
message-header-format-alist, rather than hard-coding
message-shorten-references?

>  (defun notmuch-mua-reply (query-string  sender reply-all)
>(let ((args '("reply" "--format=json"))
>   reply
> @@ -125,9 +134,16 @@ list."
> ;; Overlay the composition window on that being used to read
> ;; the original message.
> ((same-window-regexps '("\\*mail .*")))
> - (notmuch-mua-mail (plist-get reply-headers :To)
> -   (plist-get reply-headers :Subject)
> -   (notmuch-plist-to-alist reply-headers)))
> +
> + ;; We modify message-header-format-alist to get around a bug in 
> message.el.
> + ;; See the comment above on notmuch-mua-insert-references.
> + (let ((message-header-format-alist
> +(append '((References . notmuch-mua-insert-references))

(cons '(References . notmuch-mua-insert-references) ...)

> +(remove-if (lambda (x) (eq (car x) 'References))
> +   message-header-format-alist

(assq-delete-all 'References (copy-alist message-header-format-alist))?

Hmm.  That's less shorter than I would have expected, but I think it's
less opaque.

Actually, if I'm reading mail-header-format correctly, the order of
this alist controls the order of the headers, so maybe what you
actually want is

(mapcar (lambda (x) (if (eq (car x) 'References)
'(References . notmuch-mua-insert-references)
   x))
message-header-format-alist)

> +   (notmuch-mua-mail (plist-get reply-headers :To)
> + (plist-get reply-headers :Subject)
> + (notmuch-plist-to-alist reply-headers
>;; Insert the message body - but put it in front of the signature
>;; if one is present
>(goto-char (point-max))
> @@ -301,3 +317,7 @@ simply runs the corresponding `message-mode' hook 
> functions."
>  ;;
>  
>  (provide 'notmuch-mua)
> +
> +;; Local Variables:
> +;; byte-compile-warnings: (not cl-functions)
> +;; End:

This won't be necessary if you use assq-delete-all or mapcar, but if
you stick with the remove-if, you should also change the
  (eval-when-compile (require 'cl))
to
  (require 'cl)

[PATCH] emacs: Suppress warnings about using cl at runtime

[Austin Clements]

It was decided in the thread starting at [0] that it is okay for
notmuch to use 'cl runtime functions.  However, by default, these
produce byte compiler warnings.  This suppresses those using
file-local variables.

[0] id:"m262g864dz.fsf at wal122.wireless-pennnet.upenn.edu"
---
 emacs/notmuch-lib.el |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
index c146748..a9191f8 100644
--- a/emacs/notmuch-lib.el
+++ b/emacs/notmuch-lib.el
@@ -266,3 +266,6 @@ was called."

 (provide 'notmuch-lib)

+;; Local Variables:
+;; byte-compile-warnings: (not cl-functions)
+;; End:
-- 
1.7.9.1

Re: [Joerg Jaspert] Bug#666027: notmuch: get a quiet option

[David Bremner]

On Wed, 28 Mar 2012 11:26:43 -0700, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 Should we subscribe the Debian BTS to the list (and the list to the
 Debian notmuch BTS), so that the list will just get all the bug reports
 directly?
 
 jamie.

Hey Jamie;

We could give it a try and see how it works.  I suspect it needs the
assistance of one of the notmuch list moderators (which I understand we
have delegates for as of a few days ago) to get the BTS able to send to
the list. Any Debian savvy volunteers to sort this out?

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

notmuch and Debian's BTS/PTS [was: Re: [Joerg Jaspert] Bug#666027: notmuch: get a quiet option]

[Andrei POPESCU]

On Jo, 29 mar 12, 07:34:15, David Bremner wrote:
 We could give it a try and see how it works.  I suspect it needs the
 assistance of one of the notmuch list moderators (which I understand we
 have delegates for as of a few days ago) to get the BTS able to send to
 the list. Any Debian savvy volunteers to sort this out?

If there's something I can do...

Does it make sense to subscribe the list to PTS[1] instead? I'd say the 
bts, bts-control, buildd, default and contact keywords[2] make sense.

[1] Package Tracking System
[2] 
http://www.debian.org/doc/manuals/developers-reference/resources.html#pkg-tracking-system

Kind regards,
Andrei
-- 
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)


signature.asc
Description: Digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [BUG/PATCH] emacs: Fix header problem in reply for emacs 23.2

[Jani Nikula]

On Wed, 28 Mar 2012 08:02:18 -0600, Adam Wolfe Gordon awg+notm...@xvx.ca 
wrote:
 The new reply code used strings instead of symbols for header names,
 which message-mail is OK with on emacs 23.3, but not 23.2. The symptom
 is that on 23.2 (and presumably on earlier versions) the reply message
 would end up with two of some headers.
 
 This fixes the problem by converting the header names to symbols of
 the type message.el usually expects before passing the headers to
 message-mail.

The patch depends on some set of the other reply fixes (*), so I applied
this on top of them. All tests pass with emacs 23.2.

Unfortunately, the emacs UI fails with Symbol's function definition is
void: remove-if when trying to reply. After a manual (require 'cl) the
UI seems to otherwise work as expected. This is probably unrelated to
this particular patch, but why is it a (eval-when-compile (require 'cl))
and not (require 'cl) in notmuch-mua.el?


BR,
Jani.


(*)
id:1332941635-21019-2-git-send-email-awg+notm...@xvx.ca
id:1332941635-21019-3-git-send-email-awg+notm...@xvx.ca
id:1332996818-15700-1-git-send-email-awg+notm...@xvx.ca

 ---
  emacs/notmuch-lib.el |5 -
  emacs/notmuch-mua.el |   10 +-
  2 files changed, 9 insertions(+), 6 deletions(-)
 
 diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
 index c146748..af46611 100644
 --- a/emacs/notmuch-lib.el
 +++ b/emacs/notmuch-lib.el
 @@ -232,9 +232,12 @@ the given type.
(or (plist-get part :content)
(notmuch-get-bodypart-internal (concat id: (plist-get msg :id)) nth 
 process-crypto)))
  
 +;; Converts a plist of headers to an alist of headers. The input plist should
 +;; have symbols of the form :Header as keys, and the resulting alist will 
 have
 +;; symbols of the form 'Header as keys.
  (defun notmuch-plist-to-alist (plist)
(loop for (key value . rest) on plist by #'cddr
 - collect (cons (substring (symbol-name key) 1) value)))
 + collect (cons (intern (substring (symbol-name key) 1)) value)))
  
  ;; Compatibility functions for versions of emacs before emacs 23.
  ;;
 diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
 index 9805d79..24918d3 100644
 --- a/emacs/notmuch-mua.el
 +++ b/emacs/notmuch-mua.el
 @@ -185,11 +185,11 @@ OTHER-ARGS are passed through to `message-mail'.
(when notmuch-mua-user-agent-function
  (let ((user-agent (funcall notmuch-mua-user-agent-function)))
(when (not (string=  user-agent))
 - (push (cons User-Agent user-agent) other-headers
 + (push (cons 'User-Agent user-agent) other-headers
  
 -  (unless (assoc From other-headers)
 -(push (cons From (concat
 - (notmuch-user-name)   (notmuch-user-primary-email) 
 )) other-headers))
 +  (unless (assq 'From other-headers)
 +(push (cons 'From (concat
 +(notmuch-user-name)   (notmuch-user-primary-email) 
 )) other-headers))
  
(apply #'message-mail to subject other-headers other-args)
(message-sort-headers)
 @@ -250,7 +250,7 @@ the From: address first.
(interactive P)
(let ((other-headers
(when (or prompt-for-sender notmuch-always-prompt-for-sender)
 -(list (cons From (notmuch-mua-prompt-for-sender))
 +(list (cons 'From (notmuch-mua-prompt-for-sender))
  (notmuch-mua-mail nil nil other-headers)))
  
  (defun notmuch-mua-new-forward-message (optional prompt-for-sender)
 -- 
 1.7.5.4
 
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: Goto command for existing search windows

[Mark Anderson]

On Tue, 27 Mar 2012 14:24:36 -0600, Mark Anderson markr.ander...@amd.com 
wrote:
 I was looking for a function which would find a buffer based on one of
 my saved searches, and perform the search if it didn't exist.
 
 I've gotten it a bit closer, if I perform the search that matches a
 saved search, then this routine will find it because of the magic in
 notmuch-search-buffer-title, but perhaps someone else feels up to
 searching through the saved searches directly?
 
 
 
 (defun notmuch-goto-or-search (optional query)
   Find a notmuch-search buffer with the given query, or run 
 \notmuch search\ with the given `query' and display results.
 
 If `query' is nil, it is read interactively from the minibuffer.
   (interactive)
   (if (null query)
   (setq query (notmuch-read-query Notmuch goto-or-search: )))
   (let ((buffer-name (notmuch-search-buffer-title query)))
 (setq buf (get-buffer buffer-name)))
   
 (if (not buf)
 (notmuch-search query)
   (switch-to-buffer buf)
   )))

I have a slightly better-for-me version now:

(defun notmuch-goto-or-search (optional query)
  Find a notmuch saved-search query with the given name, or a
search with the given query, switching to an existing buffer
without changes in preference to automatically refreshing or
creating the search buffer.

If `query' is nil, it is read interactively from the minibuffer.
  (interactive)
  (if (null query)
  (setq query (notmuch-read-query Notmuch goto-or-search: )))
  (let ((saved-search-tuple (assoc query notmuch-saved-searches)))
(setq expanded-query
  (if (null saved-search-tuple)
  query
(cdr saved-search-tuple
  (let ((buffer-name (notmuch-search-buffer-title expanded-query)))
(setq buf (get-buffer buffer-name)))
(if (not buf)
(notmuch-search expanded-query)
  (switch-to-buffer buf)
  ))

This does search the saved searches to see if you entered a saved search
name.  With this I don't have to duplicate my query for saved searches
in key bindings.

(global-set-key [f8] (lambda () (interactive) (notmuch-goto-or-search Inbox)))
(global-set-key [f9] (lambda () (interactive) (notmuch-goto-or-search INBOX)))
(global-set-key [f10] (lambda () (interactive) (notmuch-goto-or-search todo)))


 I then use it something like this:
 
 (global-set-key [C-f1] (lambda () (interactive) (notmuch-goto-or-search 
 tag:inbox and tag:unread and not tag:deleted)))
 (global-set-key [C-f2] (lambda () (interactive) (notmuch-goto-or-search 
 tag:inbox and not tag:deleted)))
 (global-set-key [C-f3] 'notmuch)
 (global-set-key [C-f6] (lambda () (interactive) (notmuch-goto-or-search 
 tag:todo and not tag:deleted)))
 
 It would be better if I could use my Inbox, INBOX and todo names for the
 saved searches, but how to do that without breaking generality of
 searching the body of the email?  Do I have to define my own ss: (saved
 search) prefix or something, as I believe some others have?
 
 This is what I'm willing to do today, and it works for me, I could patch
 notmuch.el, but I wondered about answering the other questions.
 
 Also, some elisp master could hint about how to make the binding not so
 ugly. ;)
 
 Another appreciated elisp hint would be how to get the buf variable to
 go inside the let, I keep getting complaints about buffer-name not being
 defined, thus the ugly setq, which works.
 
 Enjoy,
 
 -Mark

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

[BUG/PATCH v2 0/2] emacs: Yesterday's bugfixes

[Adam Wolfe Gordon]

This is last night's two bugfixes [1] [2], combined into one series since they
won't both apply cleanly separately.

The only change to the fix for emacs 23.2 is the name of the function
notmuch-plist-to-alist is now notmuch-header-plist-to-alist, which more
accurately reflects what it does.

The References fix has been changed to use the existing formatter for
References instead of hard-coding message-shorten-references, and to keep the
headers in the same order they're in by default.

[1] id:1332943338-9708-1-git-send-email-awg+notm...@xvx.ca
[2] id:1332996818-15700-1-git-send-email-awg+notm...@xvx.ca

Adam Wolfe Gordon (2):
  emacs: Fix header problem in reply for emacs 23.2
  emacs: Fix the References header in reply

 emacs/notmuch-lib.el |7 +--
 emacs/notmuch-mua.el |   38 ++
 2 files changed, 35 insertions(+), 10 deletions(-)

-- 
1.7.5.4

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

[BUG/PATCH v2 1/2] emacs: Fix header problem in reply for emacs 23.2

[Adam Wolfe Gordon]

The new reply code used strings instead of symbols for header names,
which message-mail is OK with on emacs 23.3, but not 23.2. The symptom
is that on 23.2 (and presumably on earlier versions) the reply message
would end up with two of some headers.

This fixes the problem by converting the header names to symbols of
the type message.el usually expects before passing the headers to
message-mail.
---
 emacs/notmuch-lib.el |7 +--
 emacs/notmuch-mua.el |   12 ++--
 2 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
index c146748..0effe24 100644
--- a/emacs/notmuch-lib.el
+++ b/emacs/notmuch-lib.el
@@ -232,9 +232,12 @@ the given type.
   (or (plist-get part :content)
   (notmuch-get-bodypart-internal (concat id: (plist-get msg :id)) nth 
process-crypto)))
 
-(defun notmuch-plist-to-alist (plist)
+;; Converts a plist of headers to an alist of headers. The input plist should
+;; have symbols of the form :Header as keys, and the resulting alist will have
+;; symbols of the form 'Header as keys.
+(defun notmuch-headers-plist-to-alist (plist)
   (loop for (key value . rest) on plist by #'cddr
-   collect (cons (substring (symbol-name key) 1) value)))
+   collect (cons (intern (substring (symbol-name key) 1)) value)))
 
 ;; Compatibility functions for versions of emacs before emacs 23.
 ;;
diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index 9805d79..cfa3d61 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -127,7 +127,7 @@ list.
  ((same-window-regexps '(\\*mail .*)))
(notmuch-mua-mail (plist-get reply-headers :To)
  (plist-get reply-headers :Subject)
- (notmuch-plist-to-alist reply-headers)))
+ (notmuch-headers-plist-to-alist reply-headers)))
   ;; Insert the message body - but put it in front of the signature
   ;; if one is present
   (goto-char (point-max))
@@ -185,11 +185,11 @@ OTHER-ARGS are passed through to `message-mail'.
   (when notmuch-mua-user-agent-function
 (let ((user-agent (funcall notmuch-mua-user-agent-function)))
   (when (not (string=  user-agent))
-   (push (cons User-Agent user-agent) other-headers
+   (push (cons 'User-Agent user-agent) other-headers
 
-  (unless (assoc From other-headers)
-(push (cons From (concat
-   (notmuch-user-name)   (notmuch-user-primary-email) 
)) other-headers))
+  (unless (assq 'From other-headers)
+(push (cons 'From (concat
+  (notmuch-user-name)   (notmuch-user-primary-email) 
)) other-headers))
 
   (apply #'message-mail to subject other-headers other-args)
   (message-sort-headers)
@@ -250,7 +250,7 @@ the From: address first.
   (interactive P)
   (let ((other-headers
 (when (or prompt-for-sender notmuch-always-prompt-for-sender)
-  (list (cons From (notmuch-mua-prompt-for-sender))
+  (list (cons 'From (notmuch-mua-prompt-for-sender))
 (notmuch-mua-mail nil nil other-headers)))
 
 (defun notmuch-mua-new-forward-message (optional prompt-for-sender)
-- 
1.7.5.4

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

[BUG/PATCH v2 2/2] emacs: Fix the References header in reply

[Adam Wolfe Gordon]

In the new reply code, the References header gets inserted by
message.el using a function called message-shorten-references. Unlike
all the other header-inserting functions, it doesn't put a newline
after the header, causing the next header to end up on the same
line. In our case, this header happened to be User-Agent, so it's hard
to notice. This is probably a bug in message.el, but we need to work
around it.

This fixes the problem by wrapping message-shorten-references in a
function that inserts a newline after if necessary. This should
protect against the message.el bug being fixed in the future.
---
 emacs/notmuch-mua.el |   28 +---
 1 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index cfa3d61..9f279d9 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -90,6 +90,15 @@ list.
else if (notmuch-match-content-type (plist-get part :content-type) 
text/*)
  collect part))
 
+;; There is a bug in emacs 23's message.el that results in a newline
+;; not being inserted after the References header, so the next header
+;; is concatenated to the end of it. This function fixes the problem,
+;; while guarding against the possibility that some current or future
+;; version of emacs has the bug fixed.
+(defun notmuch-mua-insert-references (original-func header references)
+  (funcall original-func header references)
+  (unless (bolp) (insert \n)))
+
 (defun notmuch-mua-reply (query-string optional sender reply-all)
   (let ((args '(reply --format=json))
reply
@@ -125,9 +134,22 @@ list.
  ;; Overlay the composition window on that being used to read
  ;; the original message.
  ((same-window-regexps '(\\*mail .*)))
-   (notmuch-mua-mail (plist-get reply-headers :To)
- (plist-get reply-headers :Subject)
- (notmuch-headers-plist-to-alist reply-headers)))
+
+   ;; We modify message-header-format-alist to get around a bug in 
message.el.
+   ;; See the comment above on notmuch-mua-insert-references.
+   (let ((message-header-format-alist
+  (loop for pair in message-header-format-alist
+if (eq (car pair) 'References)
+collect (cons 'References 
+  (apply-partially
+   'notmuch-mua-insert-references
+   (cdr pair)))
+else
+collect pair)))
+ (notmuch-mua-mail (plist-get reply-headers :To)
+   (plist-get reply-headers :Subject)
+   (notmuch-headers-plist-to-alist reply-headers
+
   ;; Insert the message body - but put it in front of the signature
   ;; if one is present
   (goto-char (point-max))
-- 
1.7.5.4

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

Re: [BUG/PATCH v2] emacs: Fix the References header in reply

[Jameson Graef Rollins]

On Wed, Mar 28 2012, Adam Wolfe Gordon awg+notm...@xvx.ca wrote:
 In the new reply code, the References header gets inserted by
 message.el using a function called message-shorten-references. Unlike
 all the other header-inserting functions, it doesn't put a newline
 after the header, causing the next header to end up on the same
 line. In our case, this header happened to be User-Agent, so it's hard
 to notice. This is probably a bug in message.el, but we need to work
 around it.

 This fixes the problem by wrapping message-shorten-references in a
 function that inserts a newline after if necessary. This should
 protect against the message.el bug being fixed in the future.

Hey, Adam.  Thanks so much for working on this.

I just tested this patch and it does seem to fix the issue.  However, a
side effect seems to be that the References header is now appearing as
the first header in the reply buffer, rather than the last, as it used
to.  I suppose this is merely aesthetic, but I did prefer the ordering
as it was before.  Is there a way to tweak the
message-header-format-alist so that the References header appears last
again?

Given the various things that are being affected by this, it would
probably be good to add a test for this as well.

jamie.


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

Re: [BUG/PATCH v2] emacs: Fix the References header in reply

[Adam Wolfe Gordon]

Hi Jamie,

On Thu, Mar 29, 2012 at 11:14, Jameson Graef Rollins
jroll...@finestructure.net wrote:
 I just tested this patch and it does seem to fix the issue.  However, a
 side effect seems to be that the References header is now appearing as
 the first header in the reply buffer, rather than the last, as it used
 to.  I suppose this is merely aesthetic, but I did prefer the ordering
 as it was before.  Is there a way to tweak the
 message-header-format-alist so that the References header appears last
 again?

That's actually fixed by the new version [1]. As Austin mentioned in
his review, the order of message-header-format-alist determines the
order of the headers.

[1] id:1333038410-17927-3-git-send-email-awg+notm...@xvx.ca

 Given the various things that are being affected by this, it would
 probably be good to add a test for this as well.

Yeah, I think a test would be good. This isn't caught by the existing
emacs reply tests because the References and User-Agent headers are
hidden by default. Is there a function in emacs to tell message-mode
to show all the headers, so we can verify that they're correct?

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

Re: [BUG/PATCH v2] emacs: Fix the References header in reply

[Jameson Graef Rollins]

On Thu, Mar 29 2012, Adam Wolfe Gordon awg+notm...@xvx.ca wrote:
 That's actually fixed by the new version [1]. As Austin mentioned in
 his review, the order of message-header-format-alist determines the
 order of the headers.

 [1] id:1333038410-17927-3-git-send-email-awg+notm...@xvx.ca

Awesome!  Thanks so much Adam!  I just tested it and it works great:
solves the issue and the headers are in a nice order.  Thanks again for
the quick fix.

I see one tiny whitespace error, but overall the rest of the patches
looks great, so I say it's not worth resubmitting.  LGTM.

 Given the various things that are being affected by this, it would
 probably be good to add a test for this as well.

 Yeah, I think a test would be good. This isn't caught by the existing
 emacs reply tests because the References and User-Agent headers are
 hidden by default. Is there a function in emacs to tell message-mode
 to show all the headers, so we can verify that they're correct?

There must be, since I am seeing the In-Reply-To and References headers,
but I can't find what customization variable it is at the moment.  It
looks like I am using message-required-headers:

(message-required-headers ((optional . References) From)

But looking through the plethora of message-mode options, I think there
is probably multiple ways to set this.

jamie.


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

Re: [BUG/PATCH v2 0/2] emacs: Yesterday's bugfixes

[Austin Clements]

On Thu, 29 Mar 2012, Adam Wolfe Gordon awg+notm...@xvx.ca wrote:
 This is last night's two bugfixes [1] [2], combined into one series since they
 won't both apply cleanly separately.

 The only change to the fix for emacs 23.2 is the name of the function
 notmuch-plist-to-alist is now notmuch-header-plist-to-alist, which more
 accurately reflects what it does.

 The References fix has been changed to use the existing formatter for
 References instead of hard-coding message-shorten-references, and to keep the
 headers in the same order they're in by default.

 [1] id:1332943338-9708-1-git-send-email-awg+notm...@xvx.ca
 [2] id:1332996818-15700-1-git-send-email-awg+notm...@xvx.ca

 Adam Wolfe Gordon (2):
   emacs: Fix header problem in reply for emacs 23.2
   emacs: Fix the References header in reply

  emacs/notmuch-lib.el |7 +--
  emacs/notmuch-mua.el |   38 ++
  2 files changed, 35 insertions(+), 10 deletions(-)

LGTM.

To keep everything in one thread, Jamie also signed off this patch in
id:87obrf48ci@servo.finestructure.net.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [BUG/PATCH v2 0/2] emacs: Yesterday's bugfixes

[Jameson Graef Rollins]

On Thu, Mar 29 2012, Austin Clements amdra...@mit.edu wrote:
 To keep everything in one thread, Jamie also signed off this patch in
 id:87obrf48ci@servo.finestructure.net.

Doh.  Sorry about that.  Yes, I've tested this new version and it works
and LGTM.

jamie.


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

Re: Goto command for existing search windows

[Jameson Graef Rollins]

On Thu, Mar 29 2012, Mark Anderson markr.ander...@amd.com wrote:
 On Tue, 27 Mar 2012 14:24:36 -0600, Mark Anderson markr.ander...@amd.com 
 wrote:
 I was looking for a function which would find a buffer based on one of
 my saved searches, and perform the search if it didn't exist.
 
 I've gotten it a bit closer, if I perform the search that matches a
 saved search, then this routine will find it because of the magic in
 notmuch-search-buffer-title, but perhaps someone else feels up to
 searching through the saved searches directly?

Hey, Mark.  I think you can be a little simpler.  The title for search
buffers is based on the search, so a buffer will always be reused for an
identical search.  You don't need to do any fancy buffer searching.  For
instance, the following works perfectly for me, and I believe produces
the same results as your technique:

(defun jnotmuch-inbox ()
  Search: inbox
  (interactive)
  (notmuch-search tag:inbox t))
(define-key notmuch-hello-mode-map 2 'jnotmuch-inbox)
(define-key notmuch-search-mode-map 2 'jnotmuch-inbox)
(define-key notmuch-show-mode-map 2 'jnotmuch-inbox)

jamie.


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

Re: [PATCH] vim: fix regex after notmuch show output change

[Jakob]

On Sun, 25 Mar 2012 22:42:53 +0300, Tomi Ollila tomi.oll...@iki.fi wrote:
 I meant about the syntax: \([[0-9]*\) i.e. 2 opening [[:s

Good eye!  The regex worked, but I guess I was matching digits /and/
open-brackets.  I'll fix that.

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

Re: Goto command for existing search windows

[Jani Nikula]

On Thu, 29 Mar 2012 13:27:36 -0700, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 On Thu, Mar 29 2012, Mark Anderson markr.ander...@amd.com wrote:
  On Tue, 27 Mar 2012 14:24:36 -0600, Mark Anderson markr.ander...@amd.com 
  wrote:
  I was looking for a function which would find a buffer based on one of
  my saved searches, and perform the search if it didn't exist.
  
  I've gotten it a bit closer, if I perform the search that matches a
  saved search, then this routine will find it because of the magic in
  notmuch-search-buffer-title, but perhaps someone else feels up to
  searching through the saved searches directly?
 
 Hey, Mark.  I think you can be a little simpler.  The title for search
 buffers is based on the search, so a buffer will always be reused for an
 identical search.  You don't need to do any fancy buffer searching.

Hi, I believe Mark's point was just switching to the buffer if it
exists, *without* refreshing or doing the query, and only doing regular
notmuch-search if a buffer doesn't exist yet.

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

[PATCH] vim: fix regex after notmuch show output change

[Jakob]

The new field excluded was added to the output and made this regex fail.
---
 vim/plugin/notmuch.vim |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/vim/plugin/notmuch.vim b/vim/plugin/notmuch.vim
index 21985c7..8f27fb9 100644
--- a/vim/plugin/notmuch.vim
+++ b/vim/plugin/notmuch.vim
@@ -48,7 +48,7 @@ let s:notmuch_defaults = {
 \ 'g:notmuch_show_part_end_regexp':  'part}'  
 ,
 \ 'g:notmuch_show_marker_regexp':'
\\(message\\|header\\|body\\|attachment\\|part\\)[{}].*$',
 \
-\ 'g:notmuch_show_message_parse_regexp': '\(id:[^ ]*\) 
depth:\([0-9]*\) match:\([0-9]*\) filename:\(.*\)$',
+\ 'g:notmuch_show_message_parse_regexp': '\(id:[^ ]*\) 
depth:\([0-9]*\) match:\([0-9]*\) excluded:\([0-9]*\) filename:\(.*\)$',
 \ 'g:notmuch_show_tags_regexp':  '(\([^)]*\))$'
   ,
 \
 \ 'g:notmuch_show_signature_regexp': '^\(-- \?\|_\+\)$'
   ,
@@ -870,7 +870,8 @@ function! s:NM_cmd_show_parse(inlines)
 let msg['id'] = m[1]
 let msg['depth'] = m[2]
 let msg['match'] = m[3]
-let msg['filename'] = m[4]
+let msg['excluded'] = m[4]
+let msg['filename'] = m[5]
 endif
 
 let in_message = 1
-- 
1.7.9.1

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

Re: Goto command for existing search windows

[Jameson Graef Rollins]

On Thu, Mar 29 2012, Jani Nikula j...@nikula.org wrote:
 Hi, I believe Mark's point was just switching to the buffer if it
 exists, *without* refreshing or doing the query, and only doing regular
 notmuch-search if a buffer doesn't exist yet.

I understand, but searches are so fast, particularly for searches that
you're doing frequently enough to map to a key binding, that I really
doubt it would ever be an issue.  It's certainly not for me.

jamie.


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

Re: [PATCH] vim: fix regex after notmuch show output change

[Tomi Ollila]

On Fri, Mar 30 2012, Jakob ja...@pipefour.org wrote:

 The new field excluded was added to the output and made this regex fail.
 ---

LGTM.

Tomi


  vim/plugin/notmuch.vim |5 +++--
  1 files changed, 3 insertions(+), 2 deletions(-)

 diff --git a/vim/plugin/notmuch.vim b/vim/plugin/notmuch.vim
 index 21985c7..8f27fb9 100644
 --- a/vim/plugin/notmuch.vim
 +++ b/vim/plugin/notmuch.vim
 @@ -48,7 +48,7 @@ let s:notmuch_defaults = {
  \ 'g:notmuch_show_part_end_regexp':  'part}'
,
  \ 'g:notmuch_show_marker_regexp':'
 \\(message\\|header\\|body\\|attachment\\|part\\)[{}].*$',
  \
 -\ 'g:notmuch_show_message_parse_regexp': '\(id:[^ ]*\) 
 depth:\([0-9]*\) match:\([0-9]*\) filename:\(.*\)$',
 +\ 'g:notmuch_show_message_parse_regexp': '\(id:[^ ]*\) 
 depth:\([0-9]*\) match:\([0-9]*\) excluded:\([0-9]*\) filename:\(.*\)$',
  \ 'g:notmuch_show_tags_regexp':  '(\([^)]*\))$'  
  ,
  \
  \ 'g:notmuch_show_signature_regexp': '^\(-- \?\|_\+\)$'  
  ,
 @@ -870,7 +870,8 @@ function! s:NM_cmd_show_parse(inlines)
  let msg['id'] = m[1]
  let msg['depth'] = m[2]
  let msg['match'] = m[3]
 -let msg['filename'] = m[4]
 +let msg['excluded'] = m[4]
 +let msg['filename'] = m[5]
  endif
  
  let in_message = 1
 -- 
 1.7.9.1

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