Show mode enhancements

Show mode enhancements

[camalot]

I started using notmuch a few days ago and was astounded at how much
more efficiently I could process email with it. For my usage I needed
a bit more flexibility in replying/forwarding messages and the ability
to conveniently save attachments.  The set of patches that follow
contain these two enhancements, a few minor fixes, and the addition of
a binding of 's' in show mode to notmuch-search.

I'd be happy to address anything neded to get these changes into shape
to be included in the main distribution.  Thanks for all your work
putting together such a promising email client.

       --- Keith

[PATCH 1/9] Explicitly require the message library

[camalot]

From: Keith Amidon <keith@nicira.com>

Functions provided by the message library were being used without
ensuring it was loaded.
---
 notmuch.el |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index d7c973c..a1efa4f 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -49,6 +49,7 @@
 
 (require 'cl)
 (require 'mm-view)
+(require 'message)
 
 (defvar notmuch-show-mode-map
   (let ((map (make-sparse-keymap)))
-- 
1.6.5.3

[PATCH 2/9] Adjust autoload comments

[camalot]

From: Keith Amidon <keith@nicira.com>

The previous location of autoload comments didn't seem to correspond
with the functions most likely to be the entry points for using
notmuch.  This change adjusts them to match those likely entry points.
---
 notmuch.el |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index a1efa4f..6400199 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -707,8 +707,6 @@ view, (remove the \"inbox\" tag from each), with
 	mode-name "notmuch-show")
   (setq buffer-read-only t))
 
-;;;###autoload
-
 (defgroup notmuch nil
   "Notmuch mail reader for Emacs."
   :group 'mail)
@@ -1002,6 +1000,7 @@ This function advances point to the next line when finished."
 		  (set 'more nil))))))
       (delete-process proc))))
 
+;;;###autoload
 (defun notmuch-search (query &optional oldest-first)
   "Run \"notmuch search\" with the given query string and display results."
   (interactive "sNotmuch search: ")
@@ -1081,6 +1080,8 @@ current search results AND that are tagged with the given tag."
    (list (notmuch-select-tag-with-completion "Filter by tag: ")))
   (notmuch-search (concat notmuch-search-query-string " and tag:" tag) notmuch-search-oldest-first))
 
+
+;;;###autoload
 (defun notmuch ()
   "Run notmuch to display all mail with tag of 'inbox'"
   (interactive)
@@ -1156,6 +1157,7 @@ results for the search terms in that line.
     (if search
 	(notmuch-search (cdr search) notmuch-search-oldest-first))))
 
+;;;###autoload
 (defun notmuch-folder ()
   "Show the notmuch folder view and update the displayed counts."
   (interactive)
-- 
1.6.5.3

[PATCH 3/9] Add key binding for notmuch-search in show-mode

[camalot]

From: Keith Amidon <keith@nicira.com>

It's not uncommon to want to start a search as a result of something
read in a message so this is convenient.
---
 notmuch.el |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index 6400199..cd6609d 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -70,6 +70,7 @@
     (define-key map (kbd "C-p") 'notmuch-show-previous-line)
     (define-key map "q" 'kill-this-buffer)
     (define-key map "r" 'notmuch-show-reply)
+    (define-key map "s" 'notmuch-search)
     (define-key map "v" 'notmuch-show-view-all-mime-parts)
     (define-key map "w" 'notmuch-show-view-raw-message)
     (define-key map "x" 'kill-this-buffer)
-- 
1.6.5.3

[PATCH 4/9] Factor out message buffer mgmt from notmuch-show-view-all-mime-parts

[camalot]

From: Keith Amidon <keith@nicira.com>

The ability to temporarily create a buffer containing only the
contents of the currently selected message in notmuch show mode is
generally useful.  This commit factors the majority of the code
required to do so out of notmuch-show-view-all-mime-parts into a macro
called with-current-notmuch-show-message and rewrites the original
function in terms of the macro.

A future set of commits will provide additional functionality using
the macro as well.
---
 notmuch.el |   20 ++++++++++++--------
 1 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index cd6609d..a71a9f7 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -283,17 +283,21 @@ buffer."
   (interactive)
   (view-file (notmuch-show-get-filename)))
 
+(defmacro with-current-notmuch-show-message (&rest body)
+  "Evaluate body with current buffer set to the text of current message"
+  `(save-excursion
+     (let ((filename (notmuch-show-get-filename)))
+       (let ((buf (generate-new-buffer (concat "*notmuch-msg-" filename "*"))))
+         (with-current-buffer buf
+           (insert-file-contents filename nil nil nil t)
+           ,@body)
+        (kill-buffer buf)))))
+
 (defun notmuch-show-view-all-mime-parts ()
   "Use external viewers (according to mailcap) to view all MIME-encoded parts."
   (interactive)
-  (save-excursion
-    (let ((filename (notmuch-show-get-filename)))
-      (switch-to-buffer (generate-new-buffer (concat "*notmuch-mime-"
-						     filename
-						     "*")))
-      (insert-file-contents filename nil nil nil t)
-      (mm-display-parts (mm-dissect-buffer))
-      (kill-this-buffer))))
+  (with-current-notmuch-show-message
+   (mm-display-parts (mm-dissect-buffer))))
 
 (defun notmuch-reply (query-string)
   (switch-to-buffer (generate-new-buffer "notmuch-draft"))
-- 
1.6.5.3

[PATCH 5/9] Forward individual messages using message-forward

[camalot]

From: Keith Amidon <keith@nicira.com>

Sometimes forwarding a message is preferable to replying and modifying
the set of recipients.  This commit provides that ability using the
message-forward function.
---
 notmuch.el |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index a71a9f7..d3d75f9 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -62,6 +62,7 @@
     ; overlays-at to query and manipulate the current overlay.
     (define-key map "a" 'notmuch-show-archive-thread)
     (define-key map "A" 'notmuch-show-mark-read-then-archive-thread)
+    (define-key map "f" 'notmuch-show-forward-current)
     (define-key map "m" 'message-mail)
     (define-key map "n" 'notmuch-show-next-message)
     (define-key map "N" 'notmuch-show-mark-read-then-next-open-message)
@@ -316,6 +317,12 @@ buffer."
   (let ((message-id (notmuch-show-get-message-id)))
     (notmuch-reply message-id)))
 
+(defun notmuch-show-forward-current ()
+  "Forward a the current message."
+  (interactive)
+  (with-current-notmuch-show-message
+   (message-forward)))
+
 (defun notmuch-show-pipe-message (command)
   "Pipe the contents of the current message to the given command.
 
-- 
1.6.5.3

[PATCH 6/9] Reply to individual messages using message library

[camalot]

From: Keith Amidon <keith@nicira.com>

As an alternative to creating a reply from the current thread, this
commit provides functions to create replies directly in emacs using
the message library.

A future commit will provide keybindings so that they are easy to
change if a different set is preferred.
---
 notmuch.el |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index d3d75f9..fe20b54 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -323,6 +323,21 @@ buffer."
   (with-current-notmuch-show-message
    (message-forward)))
 
+(defun notmuch-show-reply-current ()
+  (interactive)
+  (with-current-notmuch-show-message
+   (message-reply)))
+
+(defun notmuch-show-wide-reply-current ()
+  (interactive)
+  (with-current-notmuch-show-message
+   (message-wide-reply)))
+
+(defun notmuch-show-followup-current ()
+  (interactive)
+  (with-current-notmuch-show-message
+   (message-followup)))
+
 (defun notmuch-show-pipe-message (command)
   "Pipe the contents of the current message to the given command.
 
-- 
1.6.5.3

[PATCH 7/9] Key bindings for message library based replies

[camalot]

From: Keith Amidon <keith@nicira.com>

---
 notmuch.el |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index fe20b54..eaa5798 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -64,6 +64,9 @@
     (define-key map "A" 'notmuch-show-mark-read-then-archive-thread)
     (define-key map "f" 'notmuch-show-forward-current)
     (define-key map "m" 'message-mail)
+    (define-key map "MA" 'notmuch-show-wide-reply-current)
+    (define-key map "MR" 'notmuch-show-reply-current)
+    (define-key map "MF" 'notmuch-show-followup-current)
     (define-key map "n" 'notmuch-show-next-message)
     (define-key map "N" 'notmuch-show-mark-read-then-next-open-message)
     (define-key map "p" 'notmuch-show-previous-message)
-- 
1.6.5.3

[PATCH 8/9] Provide ability to save attachments

[camalot]

From: Keith Amidon <keith@nicira.com>

Previously the only way to save an attachment was to attempt to view
it and then save it from within the viewer program.
---
 notmuch.el |   41 +++++++++++++++++++++++++++++++++++++++++
 1 files changed, 41 insertions(+), 0 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index eaa5798..0c6b527 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -303,6 +303,47 @@ buffer."
   (with-current-notmuch-show-message
    (mm-display-parts (mm-dissect-buffer))))
 
+(defun notmuch-foreach-mime-part (function mm-handle)
+  (cond ((stringp (car mm-handle))
+         (dolist (part (cdr mm-handle))
+           (notmuch-foreach-mime-part function part)))
+        ((bufferp (car mm-handle))
+         (funcall function mm-handle))
+        (t (dolist (part mm-handle)
+             (notmuch-foreach-mime-part function part)))))
+
+(defun notmuch-count-attachments (mm-handle)
+  (let ((count 0))
+    (notmuch-foreach-mime-part
+     (lambda (p)
+       (let ((disposition (mm-handle-disposition p)))
+         (and (listp disposition)
+              (equal (car disposition) "attachment")
+              (incf count))))
+     mm-handle)
+    count))
+
+(defun notmuch-save-attachments (mm-handle &optional queryp)
+  (notmuch-foreach-mime-part
+   (lambda (p)
+     (let ((disposition (mm-handle-disposition p)))
+       (and (listp disposition)
+            (equal (car disposition) "attachment")
+            (or (not queryp)
+                (y-or-n-p
+                 (concat "Save '" (cdr (assq 'filename disposition)) "' ")))
+            (mm-save-part p))))
+   mm-handle))
+
+(defun notmuch-show-save-attachments ()
+  "Save the attachments to a message"
+  (interactive)
+  (with-current-notmuch-show-message
+   (let ((mm-handle (mm-dissect-buffer)))
+     (notmuch-save-attachments
+      mm-handle (> (notmuch-count-attachments mm-handle) 1))))
+  (message "Done"))
+
 (defun notmuch-reply (query-string)
   (switch-to-buffer (generate-new-buffer "notmuch-draft"))
   (call-process notmuch-command nil t nil "reply" query-string)
-- 
1.6.5.3

[PATCH 9/9] Key binding rearrangement for save attachments in show mode

[camalot]

From: Keith Amidon <keith@nicira.com>

The most obvious bindings for save attachments are already taken.  The
existing 'w' binding was bound to view the raw message.  This commit
moves it to 'V' which still seems somewhat mnemonic and uses 'w' for
save (write) attachments.
---
 notmuch.el |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index 0c6b527..f0e8d65 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -76,7 +76,8 @@
     (define-key map "r" 'notmuch-show-reply)
     (define-key map "s" 'notmuch-search)
     (define-key map "v" 'notmuch-show-view-all-mime-parts)
-    (define-key map "w" 'notmuch-show-view-raw-message)
+    (define-key map "V" 'notmuch-show-view-raw-message)
+    (define-key map "w" 'notmuch-show-save-attachments)
     (define-key map "x" 'kill-this-buffer)
     (define-key map "+" 'notmuch-show-add-tag)
     (define-key map "-" 'notmuch-show-remove-tag)
-- 
1.6.5.3

Re: [PATCH 6/9] Reply to individual messages using message library

[Keith Amidon]

{-- Fri, 27 Nov 2009 20:48:46 +0530: Aneesh <aneesh.kumar@linux.vnet.ibm.com> wrote: --}

  Aneesh> Hi, Really good set of patches. I am right now testing with
  Aneesh> the set of changes and found that

Thanks!

  Aneesh> a) notmuch-show-reply-current and other helpers doesn't put
  Aneesh> the mail content i am replying in the reply buffer in quoted
  Aneesh> form. What i was expecting was something similar to
  Aneesh> notmuch-show-reply but one that doesn't add all the email
  Aneesh> address.

Well, the fact that I mainly cared about message forwarding and not the
reply functions is turning out to show rather badly...  There appear to
be a number of problems with the reply functions starting with the fact
that I kill the buffer that has the original message contents in it as
soon as the reply buffer is constructed, which message doesn't really
like.  I can think of some ways around the problems but I'm getting the
sense that enhancing the notmuch C program's ability to generate
different styles of replies would be preferred to what I have done.

Forwarding works fine though... :-)

  Aneesh> b) The key-binding MA is really difficult to type. How about
  Aneesh> (kbd "M-a") ?  c) I liked the mail forward feature

My main criteria in selecting key bindings was that they not conflict
with current ones.  If this were to become the preferred way to do this
I'd be happy to change them to whatever consensus emerges.

     --- Keith

Re: Show mode enhancements

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 1346 bytes --]

On Fri, 27 Nov 2009 05:30:06 -0800, camalot@picnicpark.org wrote:
> I started using notmuch a few days ago and was astounded at how much
> more efficiently I could process email with it.

Hi Keith, welcome to notmuch!

I'm delighted to hear a positive report like that about my little
project here. [Though, frankly, it's quickly gorwing beyond just "my"
project. We're about 10 days into the "public" phase of notmuch and
already I'm only creating about half of the commits going in. That's
fantastic!]

>                                                  For my usage I needed
> a bit more flexibility in replying/forwarding messages and the ability
> to conveniently save attachments.  The set of patches that follow
> contain these two enhancements, a few minor fixes, and the addition of
> a binding of 's' in show mode to notmuch-search.

Hurrah! I'll go through each of these and review. But 's' in show mode I
know I'm going to love---I keep hitting 's' and then start typing
"tag:..." and end up archiving the current thread before I realize I'm
not doing what I think I am. :-}

> I'd be happy to address anything neded to get these changes into shape
> to be included in the main distribution.  Thanks for all your work
> putting together such a promising email client.

You're quite welcome, and thanks for your contributions!

-Carl


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 1/9] Explicitly require the message library

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 272 bytes --]

On Fri, 27 Nov 2009 05:30:07 -0800, camalot@picnicpark.org wrote:
> From: Keith Amidon <keith@nicira.com>
> 
> Functions provided by the message library were being used without
> ensuring it was loaded.

Thanks. This one at least we did just fix recently.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 2/9] Adjust autoload comments

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 548 bytes --]

On Fri, 27 Nov 2009 05:30:08 -0800, camalot@picnicpark.org wrote:
> From: Keith Amidon <keith@nicira.com>
> 
> The previous location of autoload comments didn't seem to correspond
> with the functions most likely to be the entry points for using
> notmuch.  This change adjusts them to match those likely entry points.

I had a patch (on a side branch that I must have never merged) that just
removed these autoload comments. Do these even do anything for a file
that's not being built along with all the lisp code within emacs?

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 4/9] Factor out message buffer mgmt from notmuch-show-view-all-mime-parts

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 974 bytes --]

On Fri, 27 Nov 2009 05:30:10 -0800, camalot@picnicpark.org wrote:
> From: Keith Amidon <keith@nicira.com>
> 
> The ability to temporarily create a buffer containing only the
> contents of the currently selected message in notmuch show mode is
> generally useful.  This commit factors the majority of the code
> required to do so out of notmuch-show-view-all-mime-parts into a macro
> called with-current-notmuch-show-message and rewrites the original
> function in terms of the macro.
> 
> A future set of commits will provide additional functionality using
> the macro as well.

Hurrah! I'm glad to see that you are wholly more capable with emacs lisp
than I am. I knew of lisp macros of course, but didn't know the actual
syntax for writing one.

As is probably painfully obvious, I've just been learning emacs lisp as
I've been forced to hear. And I'll be more than happy to step aside and
let experts take over. :-)

This piece is pushed.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 5/9] Forward individual messages using message-forward

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 1032 bytes --]

On Fri, 27 Nov 2009 05:30:11 -0800, camalot@picnicpark.org wrote:
> From: Keith Amidon <keith@nicira.com>
> 
> Sometimes forwarding a message is preferable to replying and modifying
> the set of recipients.  This commit provides that ability using the
> message-forward function.

This is nice functionality---we were obviously missing a "forward"
command before. So I've pushed this.

Meanwhile, this does miss one piece of functionality that we have in
"notmuch reply" which is to select the From: address based on which
configured email address of the user was found in the recipient list of
the original message being forwarded.

Any suggestion for this functionality? Does message-mode provide
something similar? And if so, should notmuch.el simply read the notmuch
configuration for the various email addresses and provide them to
message-mode? I definitely don't want new users of notmuch to have to
configure email addresses both inside of notmuch and also inside of
message-mode, for example.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 6/9] Reply to individual messages using message library

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 1615 bytes --]

On Fri, 27 Nov 2009 05:30:12 -0800, camalot@picnicpark.org wrote:
> From: Keith Amidon <keith@nicira.com>
> 
> As an alternative to creating a reply from the current thread, this
> commit provides functions to create replies directly in emacs using
> the message library.
> 
> A future commit will provide keybindings so that they are easy to
> change if a different set is preferred.

Can you fill me in a little bit here? The message-mode documentation is
quite thin on what the distinctions are between "reply", "wide-reply",
and "followup".

Meanwhile, I don't think we have any need to support different
implementations of reply, (that is---I don't want one binding for a
"notmuch-based reply" and another for a "message-mode-based reply"
without any functional difference in the result).

Instead I'd like to define what the functionality is that we want here,
and then provide that. I do like taking advantage of things like
message-mode functionality wherever it exists, so I'm happy to have the
default reply button do (with-current-notmuch-show-message
(message-reply)) or whatever.

But meanwhile, I'll *also* want to understand what the variations are
here so that we can *also* implement them inside of "notmuch reply" so
that non-emacs-based interfaces can easily get at similar functionality.

So I'm holding off on pushing this patch until I understand it better,
(and documentation strings for the new functions might help for
that---provided they have more detail than the corresponding
documentation strings for the message-mode functions being called).

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 4/9] Factor out message buffer mgmt from notmuch-show-view-all-mime-parts

[Alexander Botero-Lowry]

On Fri, 27 Nov 2009 21:10:42 -0800, Carl Worth <cworth@cworth.org> wrote:
> On Fri, 27 Nov 2009 05:30:10 -0800, camalot@picnicpark.org wrote:
> > From: Keith Amidon <keith@nicira.com>
> > 
> > The ability to temporarily create a buffer containing only the
> > contents of the currently selected message in notmuch show mode is
> > generally useful.  This commit factors the majority of the code
> > required to do so out of notmuch-show-view-all-mime-parts into a macro
> > called with-current-notmuch-show-message and rewrites the original
> > function in terms of the macro.
> > 
> > A future set of commits will provide additional functionality using
> > the macro as well.
> 
> Hurrah! I'm glad to see that you are wholly more capable with emacs lisp
> than I am. I knew of lisp macros of course, but didn't know the actual
> syntax for writing one.
> 
I actually did something similar for my html support. except I used
`with-temp-buffer' macro instead. I'm hoping that the need to ever
actually use the raw message buffer directly goes away, so I think it
would be better to use with-temp-buffer in your macro instead of the
named buffer.

Alex

Re: [PATCH 8/9] Provide ability to save attachments

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]

On Fri, 27 Nov 2009 05:30:14 -0800, camalot@picnicpark.org wrote:
> From: Keith Amidon <keith@nicira.com>
> 
> Previously the only way to save an attachment was to attempt to view
> it and then save it from within the viewer program.

Very nice, Keith. Thanks again!

I've pushed this one out as well.

While we're talking about saving attachments, here are some additional
things I'd like for anybody that cares to attempt to implement them:

1. A binding to save all attachments to a single directory, (could be on
   'W' for example).

2. The ability to save an individual attachment based on a button.

3. The ability to view an individual attachment based on a button.

Parts (2) and (3) might end up wanting to be integrated via a new
command in the notmuch command-line program for extracting a numbered
mime part from the message. That command would then be usable by the
various interfaces that don't have all the functionality that emacs has
already builtin for handling MIME messages.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 9/9] Key binding rearrangement for save attachments in show mode

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 440 bytes --]

On Fri, 27 Nov 2009 05:30:15 -0800, camalot@picnicpark.org wrote:
> The most obvious bindings for save attachments are already taken.  The
> existing 'w' binding was bound to view the raw message.  This commit
> moves it to 'V' which still seems somewhat mnemonic and uses 'w' for
> save (write) attachments.

I'm fine giving up 'w' to this---'V' for view-raw is a better mnemonic
than my original, weak, 'w' for raW.

Thanks again,

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 2/9] Adjust autoload comments

[Keith Amidon]

{-- Fri, 27 Nov 2009 21:06:45 -0800: Carl <cworth@cworth.org> wrote: --}

  Carl> On Fri, 27 Nov 2009 05:30:08 -0800, camalot@picnicpark.org wrote:
  Carl> I had a patch (on a side branch that I must have never merged)
  Carl> that just removed these autoload comments. Do these even do
  Carl> anything for a file that's not being built along with all the
  Carl> lisp code within emacs?

I was interested in them because the gentoo packaging support for emacs
includes the ability to automatically create autoloads from these
comments for installed add-on packages that then get loaded system-wide
when emacs is started.  

I've my own ebuild using this functionality right now that is just
slightly different from the one that was posted here a little while ago.
I've been meaning to merge my version with that one but haven't gotten
to it yet.

           --- Keith

Re: [PATCH 5/9] Forward individual messages using message-forward

[Keith Amidon]

{-- Fri, 27 Nov 2009 21:15:15 -0800: Carl <cworth@cworth.org> wrote: --}


  Carl> On Fri, 27 Nov 2009 05:30:11 -0800, camalot@picnicpark.org wrote:
  >> From: Keith Amidon <keith@nicira.com>
  >> Sometimes forwarding a message is preferable to replying and
  >> modifying the set of recipients.  This commit provides that ability
  >> using the message-forward function.

  Carl> This is nice functionality---we were obviously missing a
  Carl> "forward" command before. So I've pushed this.

Thanks.

  Carl> Meanwhile, this does miss one piece of functionality that we
  Carl> have in "notmuch reply" which is to select the From: address
  Carl> based on which configured email address of the user was found in
  Carl> the recipient list of the original message being forwarded.

  Carl> Any suggestion for this functionality? Does message-mode provide
  Carl> something similar? And if so, should notmuch.el simply read the
  Carl> notmuch configuration for the various email addresses and
  Carl> provide them to message-mode? I definitely don't want new users
  Carl> of notmuch to have to configure email addresses both inside of
  Carl> notmuch and also inside of message-mode, for example.

I'm sure message-mode can be tweaked either gracefully or savagely in
order to provide this.  I'd be happy to look into it although I
unfortunately don't have a lot of time to code right now. 

What are your thoughts generally about integration with things like
message mode vs. implementing more into the C program?  If you think the
message-mode enhancements will have a life I'll spend some time on this
and getting the semi-broken version of the reply functions I posted
working more correctly as well.

       --- Keith

Re: [PATCH 2/9] Adjust autoload comments

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 422 bytes --]

On Sat, 28 Nov 2009 09:27:00 -0800, Keith Amidon <camalot@picnicpark.org> wrote:
> I was interested in them because the gentoo packaging support for emacs
> includes the ability to automatically create autoloads from these
> comments for installed add-on packages that then get loaded system-wide
> when emacs is started.  

OK. Knowing that their actually useful for something, I've pushed this
out now.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 5/9] Forward individual messages using message-forward

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]

On Sat, 28 Nov 2009 09:32:00 -0800, Keith Amidon <camalot@picnicpark.org> wrote:
> What are your thoughts generally about integration with things like
> message mode vs. implementing more into the C program?  If you think the
> message-mode enhancements will have a life I'll spend some time on this
> and getting the semi-broken version of the reply functions I posted
> working more correctly as well.

My style has generally been to do whatever I think is easiest. And since
I'm a user of the emacs interface to notmuch, that often means trying to
use some of the very full-featured code within emacs first.

But then again, as you've seen, just trying to figure out to use that
code can be a challenge in and of itself. And meanwhile, the
improvements to the C program will benefit the other backends.

So when there are quick and easy things, (like calling an existing
function on an 'f' binding like above), that totally makes sense to
do. We can look at things like that as interim solutions until the C
program grows up.

Long-term, I do expect a lot of features to end up being implemented in
the C program.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 5/9] Forward individual messages using message-forward

[Keith Amidon]

{-- Sat, 28 Nov 2009 09:49:58 -0800: Carl <cworth@cworth.org> wrote: --}
  Carl> So when there are quick and easy things, (like calling an
  Carl> existing function on an 'f' binding like above), that totally
  Carl> makes sense to do. We can look at things like that as interim
  Carl> solutions until the C program grows up.

  Carl> Long-term, I do expect a lot of features to end up being
  Carl> implemented in the C program.

Thanks for your perspective on the best place for things to be
implemented.  I like the pragmatism of using what's easily available in
emacs now and moving to using functions provided by the C implementation
as they become available in the future.  

Since I have relatively limited time right now, I'll probably be a lot
more productive hacking elisp code.  I won't get too attached to that
code though... :-)

        --- Keith

Re: [PATCH 6/9] Reply to individual messages using message library

[Keith Amidon]

{-- Fri, 27 Nov 2009 21:22:36 -0800: Carl <cworth@cworth.org> wrote: --}


  Carl> On Fri, 27 Nov 2009 05:30:12 -0800, camalot@picnicpark.org wrote:
  >> From: Keith Amidon <keith@nicira.com>
  >> 
  >> As an alternative to creating a reply from the current thread, this
  >> commit provides functions to create replies directly in emacs using
  >> the message library.
  >> 
  >> A future commit will provide keybindings so that they are easy to
  >> change if a different set is preferred.

  Carl> Can you fill me in a little bit here? The message-mode
  Carl> documentation is quite thin on what the distinctions are between
  Carl> "reply", "wide-reply", and "followup".

Roughly this is my understanding of the
differences:

   reply: reply only to the sender and no other recipients
   wide reply: reply to all recipients (removing self)
   followup: mainly intended for replying to news articles I believe is
        the trigger for the Mail-Followup-To behavior.  See:

        http://www.gnu.org/software/emacs/manual/html_node/message/Mailing-Lists.html#Mailing-Lists

  Carl> Meanwhile, I don't think we have any need to support different
  Carl> implementations of reply, (that is---I don't want one binding
  Carl> for a "notmuch-based reply" and another for a
  Carl> "message-mode-based reply" without any functional difference in
  Carl> the result).

I agree.  It wasn't clear to me when each type of behavior was useful
and so I erred on the side of making everything available with long
key bindings with the idea that as it became clear what was most useful
the common short key bindings could get those functions.

  Carl> Instead I'd like to define what the functionality is that we
  Carl> want here, and then provide that. I do like taking advantage of
  Carl> things like message-mode functionality wherever it exists, so
  Carl> I'm happy to have the default reply button do
  Carl> (with-current-notmuch-show-message (message-reply)) or whatever.

  Carl> But meanwhile, I'll *also* want to understand what the
  Carl> variations are here so that we can *also* implement them inside
  Carl> of "notmuch reply" so that non-emacs-based interfaces can easily
  Carl> get at similar functionality.

  Carl> So I'm holding off on pushing this patch until I understand it
  Carl> better, (and documentation strings for the new functions might
  Carl> help for that---provided they have more detail than the
  Carl> corresponding documentation strings for the message-mode
  Carl> functions being called).

I'll try to improve my docstings next time around.  Sorry about that!

        --- Keith

Re: [PATCH 2/9] Adjust autoload comments

[James Rowe]

On Sat, 28 Nov 2009 09:27:00 -0800, Keith Amidon <camalot@picnicpark.org> wrote:
> I was interested in them because the gentoo packaging support for emacs
> includes the ability to automatically create autoloads from these
> comments for installed add-on packages that then get loaded system-wide
> when emacs is started.  

  I have to admit I played with elisp-make-autoload-file in my ebuild
initially, but came to the conclusion there wasn't a great deal of
purpose to exposing more than the main notmuch function. Mostly because
it muddies my emacs and shell autocompletion, and my laziness prevailed.
Am I missing some obviously useful things that can be done if
notmuch-{folder,search} are available directly?

  I just pushed out an update that uses it, mostly so I can see the
reaction of my work colleagues in the morning. So, it may or may not be
there by lunchtime GMT tomorrow :)

> I've my own ebuild using this functionality right now that is just
> slightly different from the one that was posted here a little while ago.
> I've been meaning to merge my version with that one but haven't gotten
> to it yet.

  Post a link! If it is better than mine I'll happily switch our
installs to it.
 
  If you're merging the two please look at the github version[1] as it
is significantly different from the version I originally posted, almost
entirely as a result of the helpful contributions from others.

  I had planned on posting a patch for inclusion in packaging/Gentoo per
Carl's mail[2], but the whole GPL 2 vs 3 thing made me put it on the
backburner and I haven't looked again. Might still be useful to people
unless there is going to be a "real" release soon, as then it would be
easier to push for it on bugs.gentoo.org.

1. http://github.com/JNRowe/misc-overlay/tree/master/mail-client/notmuch/
2. id:87lji1k014.fsf@yoom.home.cworth.org
-- 
Thanks,

James

Re: [PATCH 2/9] Adjust autoload comments

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 1034 bytes --]

On Mon, 30 Nov 2009 20:38:00 +0000, James Rowe <jnrowe@gmail.com> wrote:
>   I have to admit I played with elisp-make-autoload-file in my ebuild
> initially, but came to the conclusion there wasn't a great deal of
> purpose to exposing more than the main notmuch function. Mostly because
> it muddies my emacs and shell autocompletion, and my laziness prevailed.
> Am I missing some obviously useful things that can be done if
> notmuch-{folder,search} are available directly?

The notmuch-folder command is definitely a nice primary interface to
notmuch for some people. I'm seriously considering making it the view
that one gets with "M-x notmuch" (after the notmuch-folder view gets a
little sprucing up).

As for notmuch-search, I find it very convenient to have the ability to
do a "M-x notmuch-search" (or perhaps even a simpler keybinding for it)
From any random emacs buffer. If you don't live inside emacs, and just
have a single emacs frame open for notmuch sake, maybe that's not as
interesting.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 2/9] Adjust autoload comments

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 747 bytes --]

On Mon, 30 Nov 2009 20:38:00 +0000, James Rowe <jnrowe@gmail.com> wrote:
>   I had planned on posting a patch for inclusion in packaging/Gentoo per
> Carl's mail[2], but the whole GPL 2 vs 3 thing made me put it on the
> backburner and I haven't looked again. Might still be useful to people
> unless there is going to be a "real" release soon, as then it would be
> easier to push for it on bugs.gentoo.org.

Is the GPLv3 a problem for you and your ebuild for some reason, or is it
just that you happened to start with a GPLv2 file or so?

I'm definitely interested in hearing, since this is the first project
I've let loose myself under the GPLv3. So far, it hasn't seemed to be a
big impediment to contributions, which I think is great.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 2/9] Adjust autoload comments

[Jameson Graef Rollins]

[-- Attachment #1: Type: text/plain, Size: 464 bytes --]

On Thu, Dec 03, 2009 at 05:04:52PM -0800, Carl Worth wrote:
> The notmuch-folder command is definitely a nice primary interface to
> notmuch for some people. I'm seriously considering making it the view
> that one gets with "M-x notmuch" (after the notmuch-folder view gets a
> little sprucing up).

I actually really like having notmuch open right into my "inbox".  I
thought part of the point of notmuch was to get rid of the whole dump
idea of folders!

jamie.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 2/9] Adjust autoload comments

[James Rowe]

  Firstly, thanks for the full explanations!

On Thu, 03 Dec 2009 17:04:52 -0800, Carl Worth <cworth@cworth.org> wrote:
> The notmuch-folder command is definitely a nice primary interface to
> notmuch for some people. I'm seriously considering making it the view
> that one gets with "M-x notmuch" (after the notmuch-folder view gets a
> little sprucing up).

  Coming from sup and being a gmail user "emacs -f notmuch" seems like
the natural mail interface to me. Still, even if the default view
changes I can switch to just opening a tag:inbox search.

  I've left the elisp-make-autoload-file change in our builds, which
means all the ";;;###autoload" enveloped functions are available. Nobody
seems to be upset by the change.

> As for notmuch-search, I find it very convenient to have the ability to
> do a "M-x notmuch-search" (or perhaps even a simpler keybinding for it)
> From any random emacs buffer. If you don't live inside emacs, and just
> have a single emacs frame open for notmuch sake, maybe that's not as
> interesting.

  Carl, you've got me pegged.  I use the /other/ editor, I only
installed emacs for notmuch.

  For me, I've already managed to train myself to just fire up notmuch
and hit 's' when searching. The extra search buffer that method creates
makes no difference to my personal usage patterns.

-- 
Thanks,

James

Re: [PATCH 2/9] Adjust autoload comments

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]

On Thu, 3 Dec 2009 20:24:59 -0500, Jameson Graef Rollins <jrollins@finestructure.net> wrote:
> I actually really like having notmuch open right into my "inbox".

Well, at least that option won't ever go away. :-)

> I thought part of the point of notmuch was to get rid of the whole dump
> idea of folders!

There's certainly lots of brain-damage in "folder-based" email
programs. And obviously, we don't want to encourage that. I think one of
the biggest things that notmuch provides to avoid the brain damage is
global search.

So what I'm imagining for the default notmuch view is something like
this:

	Welcome to notmuch.

	    Notmuch search: _________________________________________

	Saved searches:

	    55,342	All messages
	        22	Inbox

	Recent searches:

	         1	from:"someone special" and tag:unread
		34	tag:notmuch and tag:todo

	Click (or press Enter) on any search to see the results.
	Right-click (or press Space) on any recent search to save it.

So the "saved searches" portion of the view is basically just what
notmuch-folder displays now. Above that there's an obvious place to
start a new search, (in a slightly more "web-browser-like" way than the
typical mini-buffer approach).

All recent searches appear in the list at the bottom automatically, and
there's the documented mechanism for saving a search, (giving it a name
and having it appear above).

I think the above should do a good job of emphasizing what notmuch is,
and how a search-based email program is fundamentally different than a
folder-based approach.

Feedback?

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 2/9] Adjust autoload comments

[James Rowe]

[-- Attachment #1: Type: text/plain, Size: 1557 bytes --]

  [Sorry, I'm flipping back and forth between mail clients at the moment and
I appear to have inadvertently marked a lot of mail as read that wasn't.]

Excerpts from Carl's message of Fri Dec 04 01:07:07 +0000 2009:
> On Mon, 30 Nov 2009 20:38:00 +0000, James Rowe wrote:
> >   I had planned on posting a patch for inclusion in packaging/Gentoo per
> > Carl's mail[2], but the whole GPL 2 vs 3 thing made me put it on the
> > backburner and I haven't looked again. Might still be useful to people
> > unless there is going to be a "real" release soon, as then it would be
> > easier to push for it on bugs.gentoo.org.
>
> Is the GPLv3 a problem for you and your ebuild for some reason, or is it
> just that you happened to start with a GPLv2 file or so?

  GPL v3 isn't a problem for me personally.  The problem is Gentoo ebuilds in
the main tree are all GPL v2, and I accepted changes with a clear GPL v2 header
on the ebuild.  I don't claim to understand the licensing stuff enough to know
if mixing the two together is valid, so I just moved on to something more fun.

  I might have pushed the issue if it was important, but it isn't even
a valuable change.

> I'm definitely interested in hearing, since this is the first project
> I've let loose myself under the GPLv3. So far, it hasn't seemed to be a
> big impediment to contributions, which I think is great.

  It definitely doesn't seem to have been an impediment.  git-rank-contributors
shows 29 contributors already, and that is very impressive given the age of the
project.
-- 
Thanks,

James

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 290 bytes --]

Re: [PATCH 2/9] Adjust autoload comments

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 1664 bytes --]

On Thu, 17 Dec 2009 17:17:12 +0000, "James Rowe" <jnrowe@gmail.com> wrote:
>   [Sorry, I'm flipping back and forth between mail clients at the moment and
> I appear to have inadvertently marked a lot of mail as read that
> wasn't.]

No worries. I don't even have the excuse of flipping back and forth, and
I keep messing up my mail too.

Most recently I realized that just moving existing mail files into the
mail store keeps them hidden from notmuch, (the mtime of the containing
directory is updated, but the mtime of the file itself is still older so
gets ignored). This bug will be fixed with the rewrite of new-file
detection (with support for deleted/renamed files). I'll be landing that
soon (promise!).

>   GPL v3 isn't a problem for me personally.

OK. Thanks for following up.

>                                             The problem is Gentoo ebuilds in
> the main tree are all GPL v2, and I accepted changes with a clear GPL v2 header
> on the ebuild.  I don't claim to understand the licensing stuff enough to know
> if mixing the two together is valid, so I just moved on to something more fun.

GPLv2 and GPLv3 are incompatible by design. So there's no way to mix
them unless the code with the GPLv2 license has a notice that says
"either version 2 of the License, or (at your option) any later
version."

>   It definitely doesn't seem to have been an impediment.  git-rank-contributors
> shows 29 contributors already, and that is very impressive given the age of the
> project.

I agree. It's delightful to have so much help on the project
already. (And a bunch more will be landing soon once I start working
through my patch backlog.)

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]