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)