[PATCH] Restore original keybinding ('r' = reply-to-all)

[PATCH] Restore original keybinding ('r' = reply-to-all)

[Carl Worth]

Since the beginning of time, the emacs interface provided a keybinding
of 'r' to reply to a message, (and originally, all recipients).

Then, before release 0.12 the emacs interface acquired a new
reply-to-sender only feature. In commit
f02b475fa781bb5df3358c73213e7633a99f016e the new feature was put onto
the original keybinding, (and reply-to-all was moved to 'R').

This restores the original keybinding and uses the new keybinding for
the new feature.
---

The commit message above motivates this change from the point of view
of interface compatibility. That argument would have been stronger if
I had made it in January, (at the time of the change), rather than
now, (since there's now a new incompatiblity made by changing things
back).

That said, I still think the compatibility argument is sound.

I have other feelings as to which reply behavior should be treated
preferentially. But those are potentially more controversial, so I'll
leave the bikeshedding out of our commit history.

Thanks to everyone keeping notmuch alive and well during my extended
absence from maintainership. What a tremendous free-software success
story this all is. I'm so grateful to all of you.

-Carl

 emacs/notmuch-show.el |    4 ++--
 emacs/notmuch.el      |    4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 4349836..399a8bd 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -1145,8 +1145,8 @@ reset based on the original query."
 	(define-key map "s" 'notmuch-search)
 	(define-key map "m" 'notmuch-mua-new-mail)
 	(define-key map "f" 'notmuch-show-forward-message)
-	(define-key map "r" 'notmuch-show-reply-sender)
-	(define-key map "R" 'notmuch-show-reply)
+	(define-key map "r" 'notmuch-show-reply)
+	(define-key map "R" 'notmuch-show-reply-sender)
 	(define-key map "|" 'notmuch-show-pipe-message)
 	(define-key map "w" 'notmuch-show-save-attachments)
 	(define-key map "V" 'notmuch-show-view-raw-message)
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index c6236db..3a6b025 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -215,8 +215,8 @@ For a mouse binding, return nil."
     (define-key map ">" 'notmuch-search-last-thread)
     (define-key map "p" 'notmuch-search-previous-thread)
     (define-key map "n" 'notmuch-search-next-thread)
-    (define-key map "r" 'notmuch-search-reply-to-thread-sender)
-    (define-key map "R" 'notmuch-search-reply-to-thread)
+    (define-key map "r" 'notmuch-search-reply-to-thread)
+    (define-key map "R" 'notmuch-search-reply-to-thread-sender)
     (define-key map "m" 'notmuch-mua-new-mail)
     (define-key map "s" 'notmuch-search)
     (define-key map "o" 'notmuch-search-toggle-order)
-- 
1.7.10

Re: [PATCH] Restore original keybinding ('r' = reply-to-all)

[Jameson Graef Rollins]

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

On Wed, Jun 27 2012, Carl Worth <cworth@cworth.org> wrote:
> Since the beginning of time, the emacs interface provided a keybinding
> of 'r' to reply to a message, (and originally, all recipients).
>
> Then, before release 0.12 the emacs interface acquired a new
> reply-to-sender only feature. In commit
> f02b475fa781bb5df3358c73213e7633a99f016e the new feature was put onto
> the original keybinding, (and reply-to-all was moved to 'R').
>
> This restores the original keybinding and uses the new keybinding for
> the new feature.

I actually rebound these keys immediately after the release, so I'm
perfectly happy to change back.

jamie.

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

Re: [PATCH] Restore original keybinding ('r' = reply-to-all)

[Daniel Schoepe]

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

On Wed, 27.06.2012 19:55, Jameson Graef Rollins wrote:
> I actually rebound these keys immediately after the release, so I'm
> perfectly happy to change back.

Same here.

I think the ratio of cases where I wanted to reply to all
participants instead compared to just to the sender is something like
10:1.

Moreover, it's significantly easier to just remove recipients from the
headers than adding them, since one may no longer know who they are
after pressing reply, for example in big threads on mailing lists.

So these are my bikeshedding arguments for this change, but the last
point is not _that_ subjective, I hope.

Cheers,
Daniel

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

Re: [PATCH] Restore original keybinding ('r' = reply-to-all)

[David Bremner]

On Wed, 27 Jun 2012 10:55:53 -0700, Jameson Graef Rollins <jrollins@finestructure.net> wrote:
> On Wed, Jun 27 2012, Carl Worth <cworth@cworth.org> wrote:
> > Since the beginning of time, the emacs interface provided a keybinding
> > of 'r' to reply to a message, (and originally, all recipients).
> >
> > Then, before release 0.12 the emacs interface acquired a new
> > reply-to-sender only feature. In commit
> > f02b475fa781bb5df3358c73213e7633a99f016e the new feature was put onto
> > the original keybinding, (and reply-to-all was moved to 'R').
> >
> > This restores the original keybinding and uses the new keybinding for
> > the new feature.

My bias is probably apparent in that I pushed the original patch...

I think the there is potential for unfortunate mistakes with either set
of bindings. On the one hand sending replies to unintended people can be
very embarrassing. On the other hand, forgetting to reply to the group
can also be problematic.  The latter is easier to correct, _if_ it is
detected.

When we discussed this earlier, there were people who supported both
options as default. I broke the tie based on my experience with other
mailers, and the fact that apparently I worry more about sending things
to too many people than to too few. Obviously Carl would have chosen
differently.

It would be easy enough to add a customization variable to swap the
outcomes of r and R; iirc this is what wanderlust (or maybe VM) does. It
seems that would not really make people any happier, since the complaint
is not that it is hard to do the keybindings, but that the bindings
changed.

I do worry that by changing back, we annoy a whole new set of
people. I'm not worried for myself; I can add the equivalent keybindings
to my .emacs. I do (hypothetically) sympathize with people who just got
used to the new behaviour and are surprised again.

Anyway, if there is consensus that changing back is the right thing to
do, then I can live with that.

d

Re: [PATCH] Restore original keybinding ('r' = reply-to-all)

[Mark Walters]

On Thu, 28 Jun 2012, David Bremner <david@tethera.net> wrote:
> On Wed, 27 Jun 2012 10:55:53 -0700, Jameson Graef Rollins <jrollins@finestructure.net> wrote:
>> On Wed, Jun 27 2012, Carl Worth <cworth@cworth.org> wrote:
>> > Since the beginning of time, the emacs interface provided a keybinding
>> > of 'r' to reply to a message, (and originally, all recipients).
>> >
>> > Then, before release 0.12 the emacs interface acquired a new
>> > reply-to-sender only feature. In commit
>> > f02b475fa781bb5df3358c73213e7633a99f016e the new feature was put onto
>> > the original keybinding, (and reply-to-all was moved to 'R').
>> >
>> > This restores the original keybinding and uses the new keybinding for
>> > the new feature.
>
> My bias is probably apparent in that I pushed the original patch...
>
> I think the there is potential for unfortunate mistakes with either set
> of bindings. On the one hand sending replies to unintended people can be
> very embarrassing. On the other hand, forgetting to reply to the group
> can also be problematic.  The latter is easier to correct, _if_ it is
> detected.
>
> When we discussed this earlier, there were people who supported both
> options as default. I broke the tie based on my experience with other
> mailers, and the fact that apparently I worry more about sending things
> to too many people than to too few. Obviously Carl would have chosen
> differently.
>
> It would be easy enough to add a customization variable to swap the
> outcomes of r and R; iirc this is what wanderlust (or maybe VM) does. It
> seems that would not really make people any happier, since the complaint
> is not that it is hard to do the keybindings, but that the bindings
> changed.
>
> I do worry that by changing back, we annoy a whole new set of
> people. I'm not worried for myself; I can add the equivalent keybindings
> to my .emacs. I do (hypothetically) sympathize with people who just got
> used to the new behaviour and are surprised again.

Hi 

I agree with David on all the above and I do think that the fact that
most other mail user agents (in my experience) default to reply to
sender is a point in favour of the status quo. 

Of course, it is not my project so I am happy to go along with whatever
choice is made.

On a practical note to help with Daniel's point that it is easier to
remove recipients than add them: would it be possible to add a key
command to message mode to add the other addresses? Or put the other
addresses into the kill ring so they could be pasted into a cc line?

Best wishes

Mark

Re: [PATCH] Restore original keybinding ('r' = reply-to-all)

[Jani Nikula]

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

On Jun 28, 2012 3:06 AM, "David Bremner" <david@tethera.net> wrote:
> > On Wed, Jun 27 2012, Carl Worth <cworth@cworth.org> wrote:
> > > This restores the original keybinding and uses the new keybinding for
> > > the new feature.
>
> My bias is probably apparent in that I pushed the original patch...

And mine in that I sent the original patch. And that's pretty much the only
reason for me to not steer clear of this discussion. I'll just say I'm not
opposed to changing back.

> Anyway, if there is consensus that changing back is the right thing to
> do, then I can live with that.

Me too.

BR,
Jani.

[-- Attachment #2: Type: text/html, Size: 828 bytes --]

Re: [PATCH] Restore original keybinding ('r' = reply-to-all)

[Jesse Rosenthal]

On Wed, 27 Jun 2012, David Bremner <david@tethera.net> wrote:
> My bias is probably apparent in that I pushed the original patch...

And mine in that the first thing I did in my .emacs, back in 2009 or so,
was write a reply-to-sender function, and reverse the behavior. In fact,
I just got around to using the built-in behavior in the last couple of
weeks or so.

> I think the there is potential for unfortunate mistakes with either set
> of bindings. On the one hand sending replies to unintended people can be
> very embarrassing. 

Or something close to career-threatening. If you are in an office
situation with non-technical folks, which I am, and which more and more
of our users will likely be, replying-all accidentally can be quite
dire. The deans and the chair of my department frequently send out
requests for votes or comments to the whole department or faculty. In
many cases, the information requested is ridiculously confidential for
the medium; an accidental reply-all would be -- and I'm not overstating
-- disastrous. Incidences of this are rare, because it's not the default
in most standard clients. Even those coming from mutt or gnus are likely
to be surprised.

If it's not obvious, I'm pretty strongly against Carl's roll-back.  I
could, of course, just uncomment my old correction in my .emacs, but I
think it's a change that could hurt users. Those who are more likely to
prefer the reply-all behavior are more likely to be able to change the
defaults. Those who aren't likely to change the defaults are more likely
to be bitten, badly, by a default reply-all behavior.

> On the other hand, forgetting to reply to the group can also be
> problematic.

True that. My solution to this has been to write what I call a
"smart-reply" function -- it replies-all when you want it to, and
replies-to-sender the rest of the time. It's pretty simple, and I sent
it into the list before[0], but the basic functionality is that I give
it a list of to: addresses that I will want to reply-all to by default
(essentially, my mailing lists), and those will, by default, reply
all. Others will by default be reply-to-sender. I realize this
complicates the setup a bit, but it makes everyday use quite easy.

Best,

Jesse

[0] id:"87hay8xdoe.fsf@jhu.edu"

Re: [PATCH] Restore original keybinding ('r' = reply-to-all)

[Philip Hands]

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

Jesse Rosenthal <jrosenthal@jhu.edu> writes:

...
> If it's not obvious, I'm pretty strongly against Carl's roll-back.  I
> could, of course, just uncomment my old correction in my .emacs, but I
> think it's a change that could hurt users. Those who are more likely to
> prefer the reply-all behavior are more likely to be able to change the
> defaults. Those who aren't likely to change the defaults are more likely
> to be bitten, badly, by a default reply-all behavior.

I find the change to the new (only reply to sender) behaviour serously
irritating, because it seems I cannot train myself to hit R all the time
(which is pretty much what I always want).

On the other hand, I'm perfectly capable of customising this, but have
something of a fetish for at least trying to live with defaults for a
period, so it's my own fault for putting up with it.

So, even if I don't personally like it this way round, it is at least
fail-safe (well except for the fact that I keep failing to group-reply
and then wonder why nobody talks to me any more ;-)

Of course, if it turns out that the vast majority of actual users are
like me and would prefer to do r and then edit the To/Cc if it's
supposed to be private, then reverting the change would make sense.

Cheers, Phil.

P.S.  Oh ARSE! -- of course I just failed to hit R again! and so had to
do some more sodding about to actually get the list included in the To:

Actually, instead of either of these options, how about some way of
letting r do the single reply, and then once inside the reply, having
some key binding to add the rest of the recipients in the group, or flip
between the two options so one can change one's mind after typing up the
reply?
-- 
|)|  Philip Hands [+44 (0)20 8530 9560]    http://www.hands.com/
|-|  HANDS.COM Ltd.                    http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND

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

Re: [PATCH] Restore original keybinding ('r' = reply-to-all)

[Jameson Graef Rollins]

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

On Thu, Jun 28 2012, Mark Walters <markwalters1009@gmail.com> wrote:
> Of course, it is not my project so I am happy to go along with whatever
> choice is made.

I think everyone who has put in time and effort to make the project
great can claim a little bit of ownership.  And that certainly includes
you, Mark.

jamie.

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

Re: [PATCH] Restore original keybinding ('r' = reply-to-all)

[Jameson Graef Rollins]

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

On Thu, Jun 28 2012, Philip Hands <phil@hands.com> wrote:
> Actually, instead of either of these options, how about some way of
> letting r do the single reply, and then once inside the reply, having
> some key binding to add the rest of the recipients in the group, or flip
> between the two options so one can change one's mind after typing up the
> reply?

This is a good idea.  The other idea I had was to have 'r' query the
user directly about whether or not they want to reply all before
constructing the reply template.  Or right before you're about to send.

jamie.

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

Re: [PATCH] Restore original keybinding ('r' = reply-to-all)

[Thomas Jost]

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

Le 28 juin 2012 à 18:21 CEST, Jameson Graef Rollins a écrit :
> On Thu, Jun 28 2012, Philip Hands <phil@hands.com> wrote:
>> Actually, instead of either of these options, how about some way of
>> letting r do the single reply, and then once inside the reply, having
>> some key binding to add the rest of the recipients in the group, or flip
>> between the two options so one can change one's mind after typing up the
>> reply?
>
> This is a good idea.  The other idea I had was to have 'r' query the
> user directly about whether or not they want to reply all before
> constructing the reply template.  Or right before you're about to send.

In my config, I use "r a" for "reply to all" and "r s" for "reply to
sender". Never got it wrong since I added this to my .emacs.
https://github.com/Schnouki/dotfiles/blob/master/emacs/init-50-mail.el#L111-114

Regards,
-- 
Thomas/Schnouki

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

Re: [PATCH] Restore original keybinding ('r' = reply-to-all)

[Carl Worth]

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

Philip Hands <phil@hands.com> writes:
> I find the change to the new (only reply to sender) behaviour serously
> irritating, because it seems I cannot train myself to hit R all the time
> (which is pretty much what I always want).

I'm in a similar camp. I tried (and failed) to adopt to the current
mode, (once I realized that the change had happened and that I had been
mis-replying).

I think part of the problem with training here is that if your mental
model is "I generally want to reply to all, and exceptionally want to
reply to only some" then the 'r == reply-to-sender' often does do what
you want. That is, when the CC list is empty, reply-to-sender is no
different than reply-to-all. So there's some mis-training that occurs,
('r' seems to do what I want). Worse, the results of the mis-training
are hidden from the user, (since if the user didn't pay attention to the
CC list before hitting 'r', the unintentional culling of recipients is
hidden within the composition buffer).

For me, personally, I tend to do a final examination of my message just
before sending. This is a quick scan to look for typos, make sure my
message is clear, etc. During part of this scan, it's also natural for
me to ensure that there isn't anyone in the recipient list that
shouldn't be receiving the message. If I do decide to remove some
recipients from my message, this is a natural time for me to do it, (or
perhaps earlier, during composition, when first writing something
sensitive).

So, for me, making a decision *before* writing anything doesn't fit my
mental model, (I'll often change the tone of my message while composing,
and in ways that the recipient list might change).

I also find reply-to-sender-only too limiting of an operation, (compared
to reply-to-all followed by header editing). For example, sometimes I
might want to drop some smaller subset of recipients from my reply.

My workflow is definitely influenced my the habits of coworkers in my
corporate environment. While there are many mailing-list addresses,
there are often large threads involving ad-hoc recipient lists. And as
conversations go, some groups of individuals needs to be added or
removed from the discussion. Header editing works for that, in a way
that reply-to-sender doesn't help.

> On the other hand, I'm perfectly capable of customising this, but have
> something of a fetish for at least trying to live with defaults for a
> period, so it's my own fault for putting up with it.

I'm obviously capable of making a customization as well, (and have done
so). The current mechanism[*] I'm using for this customization is
particularly clumsy, (it's not exposed in the customize buffer, it
requires the user to know the names of internal objects like
notmuch-show-mode-map and notmuch-search-reply-to-thread-sender), and it
requires the user to change 4 settings, (in two separate places), in
order to get a consistent experience, (so it would be easy to
accidentally make search-mode and show-mode behave differently).

There's clearly difference of opinion on what the defaults should be. So
at the very least, we should make it easier to customize this.

How about the following:

  With no customization in place, the first time the user hits 'r',
  notmuch prompts with something like:

    Reply to all or sender only? [asAS?]:

  Hitting '?' would the provide more instructions:

    'a': Reply to all recipients for this reply.
    's': Reply to sender-only for this reply.
    'A': Reply to all recipients now and in the future (no questions asked)
    'S': Reply to sender-only now and in the future (no questions asked)

     Note: After setting a default behavior with 'A' or 'S' here, the
     alternate behavior can still be obtained by initiating a reply with
     'R' rather than 'r'.

That would satisfy me as being sufficiently easy-to-use and sufficiently
self-documenting.

It also as the advantage of letting us make a change now without
tripping up any users.

I think the implementation should function by setting a single
customize-based variable. But care should be taken such that the notmuch
help modes still correctly describe what 'r' and 'R' do depending on how
this variable is configured. My current approach of setting a preference
by changing the keybindings yields correct documentation "for
free". It's probably a little trickier to get that correct documentation
with a single variable controlling things, but I hope it's not too hard.

Anyone care to attempt an implementation of this?

-Carl

[*] Here's what I'm using now:

(define-key notmuch-show-mode-map "r" 'notmuch-show-reply)
(define-key notmuch-show-mode-map "R" 'notmuch-show-reply-sender)
(define-key notmuch-search-mode-map "r" 'notmuch-search-reply-to-thread)
(define-key notmuch-search-mode-map "R" 'notmuch-search-reply-to-thread-sender)

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

[UGLY DFAFT PATCH] draft: emacs: custom variable to choose default reply-to behaviour

[Tomi Ollila]

This is one draft solution to provide an implementation described in
id:"87y5n7z5aj.fsf@yoom.home.cworth.org"

Comments how things could be done better (or totally different way)
are welcome -- and specially, if you are better than me in elisp
(which you probably are) reuse any code freely in your implementation...

There are some things missing (like declare-functions (and specially, one
`custom-set`) and new code is not necessarily located at the most suitable
places -- for now the changes are "localized" to 2 places.

This implementation uses custom variable and based on that the 4 keybindings
are set -- if custom variable is nil then bindings point to the setting
interface functions. Currenlty after later changes outside of those setting
functions does not change bindings -- in the future using
customize-save-variable that will change bindings -- but always when using
setq/set to change the (custom) variable will not change the bindings (so
the variable can be made out-of-sync with the bindings -- if that matters).
---
 emacs/notmuch-show.el |   58 +++++++++++++++++++++++++++++++++++++++++++++++-
 emacs/notmuch.el      |   23 +++++++++++++++++-
 2 files changed, 77 insertions(+), 4 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 4349836..10eb75d 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -1134,6 +1134,61 @@ reset based on the original query."
   "Submap for stash commands")
 (fset 'notmuch-show-stash-map notmuch-show-stash-map)
 
+;;; draft code ;;;
+(defcustom notmuch-reply-to-default nil
+  "Doc string (i.e. not documented yet)"
+  :type '(choice (const :tag "reply to all" 'all)
+		 (const :tag "reply to sender" 'sender))
+  ;;:custom-set 'set-default-and-keybinding
+  :group 'notmuch-send)
+
+(defun notmuch-choose-reply-keybindings ()
+  (interactive)
+  (defun ia () (interactive) (insert "a") (exit-minibuffer))
+  (defun is () (interactive) (insert "s") (exit-minibuffer))
+  (defun iA () (interactive) (insert "A") (exit-minibuffer))
+  (defun iS () (interactive) (insert "S") (exit-minibuffer))
+  (let ((map (make-keymap)))
+    (suppress-keymap map t)
+    ;;(define-key map "?" 'helep)
+    (define-key map "a" 'ia)
+    (define-key map "s" 'is)
+    (define-key map "A" 'iA)
+    (define-key map "S" 'iS)
+    (save-excursion
+      (let ((val (read-from-minibuffer
+		  "Reply to all or sender only? [asAS?]:" nil map)))
+	(cond ((string= val "a") t)
+	      ((string= val "s") nil)
+	      ((string= val "A")
+	       (customize-save-variable 'notmuch-reply-to-default 'all)
+	       (notmuch-show-set-reply-keybindings) ;; not needed when ...
+	       (notmuch-search-set-reply-keybindings) t) ;; custom-set in use.
+	      ((string= val "S")
+	       (customize-save-variable 'notmuch-reply-to-default 'sender)
+	       (notmuch-show-set-reply-keybindings) ;; not needed when ...
+	       (notmuch-search-set-reply-keybindings) nil) ;; custom-set in use
+	      )))))
+
+(defun notmuch-show-choose-reply-keybindings ()
+  (interactive)
+  (if (notmuch-choose-reply-keybindings)
+      (notmuch-show-reply)
+    (notmuch-show-reply-sender)))
+
+(defun notmuch-show-set-reply-keybindings (&optional map)
+  (unless map
+    (set 'map notmuch-show-mode-map))
+  (cond ((eq notmuch-reply-to-default 'all)
+	 (define-key map "r" 'notmuch-show-reply)
+	 (define-key map "R" 'notmuch-show-reply-sender))
+	((eq notmuch-reply-to-default 'sender)
+	 (define-key map "r" 'notmuch-show-reply-sender)
+	 (define-key map "R" 'notmuch-show-reply))
+	(t
+	 (define-key map "r" 'notmuch-show-choose-reply-keybindings)
+	 (define-key map "R" 'notmuch-show-choose-reply-keybindings))))
+
 (defvar notmuch-show-mode-map
       (let ((map (make-sparse-keymap)))
 	(define-key map "?" 'notmuch-help)
@@ -1145,8 +1200,6 @@ reset based on the original query."
 	(define-key map "s" 'notmuch-search)
 	(define-key map "m" 'notmuch-mua-new-mail)
 	(define-key map "f" 'notmuch-show-forward-message)
-	(define-key map "r" 'notmuch-show-reply-sender)
-	(define-key map "R" 'notmuch-show-reply)
 	(define-key map "|" 'notmuch-show-pipe-message)
 	(define-key map "w" 'notmuch-show-save-attachments)
 	(define-key map "V" 'notmuch-show-view-raw-message)
@@ -1174,6 +1227,7 @@ reset based on the original query."
 	(define-key map "$" 'notmuch-show-toggle-process-crypto)
 	(define-key map "<" 'notmuch-show-toggle-thread-indentation)
 	(define-key map "t" 'toggle-truncate-lines)
+	(notmuch-show-set-reply-keybindings map)
 	map)
       "Keymap for \"notmuch show\" buffers.")
 (fset 'notmuch-show-mode-map notmuch-show-mode-map)
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index c6236db..a95e191 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -203,6 +203,26 @@ For a mouse binding, return nil."
   :group 'notmuch-search
   :group 'notmuch-hooks)
 
+;;; draft code ;;;
+(defun notmuch-search-choose-reply-keybindings ()
+  (interactive)
+  (if (notmuch-choose-reply-keybindings)
+      (notmuch-search-reply-to-thread)
+    (notmuch-search-reply-to-thread-sender)))
+
+(defun notmuch-search-set-reply-keybindings (&optional map)
+  (unless map
+    (set 'map notmuch-search-mode-map))
+  (cond ((eq notmuch-reply-to-default 'all)
+	 (define-key map "r" 'notmuch-search-reply-to-thread)
+	 (define-key map "R" 'notmuch-search-reply-to-thread-sender))
+	((eq notmuch-reply-to-default 'sender)
+	 (define-key map "r" 'notmuch-search-reply-to-thread-sender)
+	 (define-key map "R" 'notmuch-search-reply-to-thread))
+	(t
+	 (define-key map "r" 'notmuch-search-choose-reply-keybindings)
+	 (define-key map "R" 'notmuch-search-choose-reply-keybindings))))
+
 (defvar notmuch-search-mode-map
   (let ((map (make-sparse-keymap)))
     (define-key map "?" 'notmuch-help)
@@ -215,8 +235,6 @@ For a mouse binding, return nil."
     (define-key map ">" 'notmuch-search-last-thread)
     (define-key map "p" 'notmuch-search-previous-thread)
     (define-key map "n" 'notmuch-search-next-thread)
-    (define-key map "r" 'notmuch-search-reply-to-thread-sender)
-    (define-key map "R" 'notmuch-search-reply-to-thread)
     (define-key map "m" 'notmuch-mua-new-mail)
     (define-key map "s" 'notmuch-search)
     (define-key map "o" 'notmuch-search-toggle-order)
@@ -231,6 +249,7 @@ For a mouse binding, return nil."
     (define-key map "-" 'notmuch-search-remove-tag)
     (define-key map "+" 'notmuch-search-add-tag)
     (define-key map (kbd "RET") 'notmuch-search-show-thread)
+    (notmuch-search-set-reply-keybindings map)
     map)
   "Keymap for \"notmuch search\" buffers.")
 (fset 'notmuch-search-mode-map notmuch-search-mode-map)
-- 
1.7.1