[PATCH] emacs: add some convenience functions to show mode

[PATCH] emacs: add some convenience functions to show mode

[Jameson Rollins]

Adding three new conveneince functions:

notmuch-show-next-open-message-or-pop
notmuch-show-next-thread
notmuch-show-previous-thread

While these are not currently bound to any keys, I have found them to
be very useful for constructing custom key bindings outside of what
notmuch provides by default.  For example:

(define-key notmuch-show-mode-map "a"
  (lambda ()
    "archive current message and advance"
    (interactive)
    (notmuch-show-remove-tag "inbox")
    (notmuch-show-next-open-message-or-pop)))
(define-key notmuch-show-mode-map "N" 'notmuch-show-next-thread)
(define-key notmuch-show-mode-map "P" 'notmuch-show-previous-thread)
---
 emacs/notmuch-show.el |   39 +++++++++++++++++++++++++++++++++++++++
 1 files changed, 39 insertions(+), 0 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index b89b685..820fd0e 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -920,6 +920,45 @@ any effects from previous calls to
   (notmuch-show-mark-read)
   (notmuch-show-message-adjust))
 
+(defun notmuch-show-next-open-message-or-pop ()
+  "Show the next message or pop out if none remain."
+  (interactive)
+  (let (r)
+    (while (and (setq r (notmuch-show-goto-message-next))
+		(not (notmuch-show-message-visible-p))))
+    (if r
+	(progn
+	  (notmuch-show-mark-read)
+	  (notmuch-show-message-adjust))
+      (let ((parent-buffer notmuch-show-parent-buffer))
+	(if parent-buffer
+	    (progn
+	      (kill-this-buffer)
+	      (switch-to-buffer parent-buffer)
+	      (forward-line 1)))))))
+
+(defun notmuch-show-next-thread ()
+  "Move to the next thread from the last search."
+  (interactive)
+  (let ((parent-buffer notmuch-show-parent-buffer))
+    (if parent-buffer
+      (progn
+        (kill-this-buffer)
+        (switch-to-buffer parent-buffer)
+        (forward-line 1)
+        (notmuch-search-show-thread)))))
+
+(defun notmuch-show-previous-thread ()
+  "Move to the previous thread from the last search."
+  (interactive)
+  (let ((parent-buffer notmuch-show-parent-buffer))
+    (if parent-buffer
+      (progn
+        (kill-this-buffer)
+        (switch-to-buffer parent-buffer)
+        (forward-line -1)
+        (notmuch-search-show-thread)))))
+
 (defun notmuch-show-view-raw-message ()
   "View the file holding the current message."
   (interactive)
-- 
1.7.2.3

Re: [PATCH] emacs: add some convenience functions to show mode

[Carl Worth]

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

On Sun, 14 Nov 2010 17:09:01 -0500, Jameson Rollins <jrollins@finestructure.net> wrote:
> While these are not currently bound to any keys, I have found them to
> be very useful for constructing custom key bindings outside of what
> notmuch provides by default.

These look fairly handy.

But, since I know our current keybindings are less-than-perfect, I would
prefer to see patches that also fix them, (rather than just adding
functionality that new users can't get at without manual customization).

Would you accept an invitation to make a proposal (with patch) to
actually improve the default keybindings here as well?

I haven't pushed the patch, while awaiting your response to the above.

-Carl

-- 
carl.d.worth@intel.com

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

Re: [PATCH] emacs: add some convenience functions to show mode

[Jameson Rollins]

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

On Tue, 16 Nov 2010 11:35:31 -0800, Carl Worth <cworth@cworth.org> wrote:
> These look fairly handy.
> 
> But, since I know our current keybindings are less-than-perfect, I would
> prefer to see patches that also fix them, (rather than just adding
> functionality that new users can't get at without manual customization).
> 
> Would you accept an invitation to make a proposal (with patch) to
> actually improve the default keybindings here as well?

Hey, Carl.  I could do this, but I think I would ultimately just be
submitting patches for notmuch to behave in the specific way that I want
it to behave.  I'm pretty sure that everyone has different ideas of what
they want, and I worry that if I start submitting my preference we'll
have to contend with lots of debate over behavior preference, leading to
lots of requests for more configuration options.  This has actually
already happened, most recently with my patch to remove thread archiving
From the show-advance function [0].

My thought instead is that if we have a nice library of useful atomic
functions, for things like tagging and thread navigation, it would make
it easy for people to construct the exact behavior they want by defining
their own functions and key bindings.  It's quite easy to do this, as
I've tried to point out in the emacstips page.  If we had good
documentation for the available functions and for how to implement
custom bindings we could make it pretty easy for users to get the exact
behavior they desire.

I could definitely submit a series of patches that would define what I
personally consider ideal behavior, but since I'm quite sure that others
would disagree with my choices, I think the patches would ultimately not
be accepted and the work would therefore not be worth the trouble.

I'm definitely not trying to sound cynical here.  I'm just trying to be
realistic about the variety of personal preference.  But like I say, I'd
be happy to impose mine on everyone else if people would be ok with it!

jamie.

[0] id:"87eiaqwmzh.fsf@servo.finestructure.net"

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

Re: [PATCH] emacs: add some convenience functions to show mode

[Carl Worth]

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

On Tue, 16 Nov 2010 15:41:10 -0500, Jameson Rollins <jrollins@finestructure.net> wrote:
> Hey, Carl.  I could do this, but I think I would ultimately just be
> submitting patches for notmuch to behave in the specific way that I want
> it to behave.  I'm pretty sure that everyone has different ideas of what
> they want, and I worry that if I start submitting my preference we'll
> have to contend with lots of debate over behavior preference, leading to
> lots of requests for more configuration options.

I don't know about contention, but that debate is exactly what I want to
encourage.

I *know* that the current set of keybindings is not ideal. It was simply
something I came up with for my own personal use once. So I don't wwant
to set it in stone just because it happens to be present already.

> This has actually
> already happened, most recently with my patch to remove thread archiving
> From the show-advance function [0].

Yes, and I want that discussion to continue. I'd like to even contribute
to it myself.

> My thought instead is that if we have a nice library of useful atomic
> functions, for things like tagging and thread navigation, it would make
> it easy for people to construct the exact behavior they want by defining
> their own functions and key bindings.

Yes. We do need useful primitive operations. But we also need the "best"
default bindings (according to some ill-defined metric, perhaps
involving executive decisions), and I'd like to see discussion to help
us ensure that our defaults are as good as possible.

What I don't want is a state where some particular defaults are used by
almost nobody, and nobody can use notmuch effectively without
customization.

> I could definitely submit a series of patches that would define what I
> personally consider ideal behavior[...]

I'd encourage you to submit these and let's discuss them. If there's no
objection then your preferred defaults can win. If there is objection,
then we know that there's some need for configurability and we can
decide what the defaults should be.

>                                     but since I'm quite sure that others
> would disagree with my choices, I think the patches would ultimately not
> be accepted and the work would therefore not be worth the trouble.

I can't guarantee that effort won't be wasted. (Many of the authors of
the patches languishing in my patch queue might already consider their
effort wasted...). But perhaps I can encourage the discussion by
refusing to accept a configuration option without evidence on the
mailing list of differing opinions on what the default should be?

> I'm definitely not trying to sound cynical here.

No need to apologize. Our community is still young and we're still
learning how to work together and how to form group decisions.

I do appreciate all of your contributions,

-Carl

-- 
carl.d.worth@intel.com

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