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

[Carl Worth]

On Tue, 16 Nov 2010 15:41:10 -0500, Jameson Rollins  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 at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 

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

[Carl Worth]

On Tue, 16 Nov 2010 15:41:10 -0500, Jameson Rollins 
jroll...@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.wo...@intel.com


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

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

[Jameson Rollins]

On Tue, 16 Nov 2010 11:35:31 -0800, Carl Worth  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

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

[Carl Worth]

On Sun, 14 Nov 2010 17:09:01 -0500, Jameson Rollins  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 at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 

[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