From: Carl Worth Date: Thu, 28 Jun 2012 17:59:16 +0000 (+1700) Subject: Re: [PATCH] Restore original keybinding ('r' = reply-to-all) X-Git-Url: http://git.tremily.us/gitweb.cgi?a=commitdiff_plain;h=4d74f85ae35f258310c482d6e36c3f7a22bb1720;p=notmuch-archives.git Re: [PATCH] Restore original keybinding ('r' = reply-to-all) --- diff --git a/2e/e7ac5291f3dd56b726b887f7aea8342d9aa21d b/2e/e7ac5291f3dd56b726b887f7aea8342d9aa21d new file mode 100644 index 000000000..3f6bdbb22 --- /dev/null +++ b/2e/e7ac5291f3dd56b726b887f7aea8342d9aa21d @@ -0,0 +1,172 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id CE190431FB6 + for ; Thu, 28 Jun 2012 10:58:21 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: 0.01 +X-Spam-Level: +X-Spam-Status: No, score=0.01 tagged_above=-999 required=5 + tests=[T_MIME_NO_TEXT=0.01] autolearn=disabled +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id Hk5TYPRccIE8 for ; + Thu, 28 Jun 2012 10:58:21 -0700 (PDT) +Received: from arlo.cworth.org (arlo.cworth.org [50.43.72.2]) + (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) + (No client certificate requested) + by olra.theworths.org (Postfix) with ESMTPS id F23A8431FAF + for ; Thu, 28 Jun 2012 10:58:20 -0700 (PDT) +Received: from yoom.home.cworth.org (localhost [127.0.0.1]) + by arlo.cworth.org (Postfix) with ESMTP id 9F46329A0D3; + Thu, 28 Jun 2012 10:58:18 -0700 (PDT) +Received: by yoom.home.cworth.org (Postfix, from userid 1000) + id 4381664EB9; Thu, 28 Jun 2012 10:59:22 -0700 (PDT) +From: Carl Worth +To: Philip Hands , Jesse Rosenthal , + David Bremner , + Jameson Graef Rollins , notmuch@notmuchmail.org +Subject: Re: [PATCH] Restore original keybinding ('r' = reply-to-all) +In-Reply-To: <87hatv4e37.fsf@poker.hands.com> +References: <1340815565-21083-1-git-send-email-cworth@cworth.org> + <87obo4zljq.fsf@servo.finestructure.net> + <87hatwqoz9.fsf@maritornes.cs.unb.ca> <87ehozmpcq.fsf@jhu.edu> + <87hatv4e37.fsf@poker.hands.com> +User-Agent: Notmuch/0.13.1 (http://notmuchmail.org) Emacs/23.4.1 + (x86_64-pc-linux-gnu) +Date: Thu, 28 Jun 2012 10:59:16 -0700 +Message-ID: <87y5n7z5aj.fsf@yoom.home.cworth.org> +MIME-Version: 1.0 +Content-Type: multipart/signed; boundary="=-=-="; + micalg=pgp-sha1; protocol="application/pgp-signature" +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Thu, 28 Jun 2012 17:58:21 -0000 + +--=-=-= + +Philip Hands 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) + +--=-=-= +Content-Type: application/pgp-signature + +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1.4.12 (GNU/Linux) + +iEYEARECAAYFAk/sm3QACgkQ6JDdNq8qSWh0+QCcCDHKkIVljuErChr6aGZaan8K +dKcAnRXB2xsmq3u4UUu6y4RKpq08FkYP +=+iKM +-----END PGP SIGNATURE----- +--=-=-=--