Philip Hands <phil at 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) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20120628/e2c844fc/attachment.pgp>