Re: [PATCH] Restore original keybinding ('r' = reply-to-all)
authorCarl Worth <cworth@cworth.org>
Thu, 28 Jun 2012 17:59:16 +0000 (10:59 +1700)
committerW. Trevor King <wking@tremily.us>
Fri, 7 Nov 2014 17:47:52 +0000 (09:47 -0800)
2e/e7ac5291f3dd56b726b887f7aea8342d9aa21d [new file with mode: 0644]

diff --git a/2e/e7ac5291f3dd56b726b887f7aea8342d9aa21d b/2e/e7ac5291f3dd56b726b887f7aea8342d9aa21d
new file mode 100644 (file)
index 0000000..3f6bdbb
--- /dev/null
@@ -0,0 +1,172 @@
+Return-Path: <cworth@cworth.org>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id CE190431FB6\r
+       for <notmuch@notmuchmail.org>; Thu, 28 Jun 2012 10:58:21 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0.01\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0.01 tagged_above=-999 required=5\r
+       tests=[T_MIME_NO_TEXT=0.01] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+       by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+       with ESMTP id Hk5TYPRccIE8 for <notmuch@notmuchmail.org>;\r
+       Thu, 28 Jun 2012 10:58:21 -0700 (PDT)\r
+Received: from arlo.cworth.org (arlo.cworth.org [50.43.72.2])\r
+       (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))\r
+       (No client certificate requested)\r
+       by olra.theworths.org (Postfix) with ESMTPS id F23A8431FAF\r
+       for <notmuch@notmuchmail.org>; Thu, 28 Jun 2012 10:58:20 -0700 (PDT)\r
+Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
+       by arlo.cworth.org (Postfix) with ESMTP id 9F46329A0D3;\r
+       Thu, 28 Jun 2012 10:58:18 -0700 (PDT)\r
+Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
+       id 4381664EB9; Thu, 28 Jun 2012 10:59:22 -0700 (PDT)\r
+From: Carl Worth <cworth@cworth.org>\r
+To: Philip Hands <phil@hands.com>, Jesse Rosenthal <jrosenthal@jhu.edu>,\r
+       David Bremner <david@tethera.net>,\r
+       Jameson Graef Rollins <jrollins@finestructure.net>, notmuch@notmuchmail.org\r
+Subject: Re: [PATCH] Restore original keybinding ('r' = reply-to-all)\r
+In-Reply-To: <87hatv4e37.fsf@poker.hands.com>\r
+References: <1340815565-21083-1-git-send-email-cworth@cworth.org>\r
+       <87obo4zljq.fsf@servo.finestructure.net>\r
+       <87hatwqoz9.fsf@maritornes.cs.unb.ca> <87ehozmpcq.fsf@jhu.edu>\r
+       <87hatv4e37.fsf@poker.hands.com>\r
+User-Agent: Notmuch/0.13.1 (http://notmuchmail.org) Emacs/23.4.1\r
+       (x86_64-pc-linux-gnu)\r
+Date: Thu, 28 Jun 2012 10:59:16 -0700\r
+Message-ID: <87y5n7z5aj.fsf@yoom.home.cworth.org>\r
+MIME-Version: 1.0\r
+Content-Type: multipart/signed; boundary="=-=-=";\r
+       micalg=pgp-sha1; protocol="application/pgp-signature"\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+       <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Thu, 28 Jun 2012 17:58:21 -0000\r
+\r
+--=-=-=\r
+\r
+Philip Hands <phil@hands.com> writes:\r
+> I find the change to the new (only reply to sender) behaviour serously\r
+> irritating, because it seems I cannot train myself to hit R all the time\r
+> (which is pretty much what I always want).\r
+\r
+I'm in a similar camp. I tried (and failed) to adopt to the current\r
+mode, (once I realized that the change had happened and that I had been\r
+mis-replying).\r
+\r
+I think part of the problem with training here is that if your mental\r
+model is "I generally want to reply to all, and exceptionally want to\r
+reply to only some" then the 'r == reply-to-sender' often does do what\r
+you want. That is, when the CC list is empty, reply-to-sender is no\r
+different than reply-to-all. So there's some mis-training that occurs,\r
+('r' seems to do what I want). Worse, the results of the mis-training\r
+are hidden from the user, (since if the user didn't pay attention to the\r
+CC list before hitting 'r', the unintentional culling of recipients is\r
+hidden within the composition buffer).\r
+\r
+For me, personally, I tend to do a final examination of my message just\r
+before sending. This is a quick scan to look for typos, make sure my\r
+message is clear, etc. During part of this scan, it's also natural for\r
+me to ensure that there isn't anyone in the recipient list that\r
+shouldn't be receiving the message. If I do decide to remove some\r
+recipients from my message, this is a natural time for me to do it, (or\r
+perhaps earlier, during composition, when first writing something\r
+sensitive).\r
+\r
+So, for me, making a decision *before* writing anything doesn't fit my\r
+mental model, (I'll often change the tone of my message while composing,\r
+and in ways that the recipient list might change).\r
+\r
+I also find reply-to-sender-only too limiting of an operation, (compared\r
+to reply-to-all followed by header editing). For example, sometimes I\r
+might want to drop some smaller subset of recipients from my reply.\r
+\r
+My workflow is definitely influenced my the habits of coworkers in my\r
+corporate environment. While there are many mailing-list addresses,\r
+there are often large threads involving ad-hoc recipient lists. And as\r
+conversations go, some groups of individuals needs to be added or\r
+removed from the discussion. Header editing works for that, in a way\r
+that reply-to-sender doesn't help.\r
+\r
+> On the other hand, I'm perfectly capable of customising this, but have\r
+> something of a fetish for at least trying to live with defaults for a\r
+> period, so it's my own fault for putting up with it.\r
+\r
+I'm obviously capable of making a customization as well, (and have done\r
+so). The current mechanism[*] I'm using for this customization is\r
+particularly clumsy, (it's not exposed in the customize buffer, it\r
+requires the user to know the names of internal objects like\r
+notmuch-show-mode-map and notmuch-search-reply-to-thread-sender), and it\r
+requires the user to change 4 settings, (in two separate places), in\r
+order to get a consistent experience, (so it would be easy to\r
+accidentally make search-mode and show-mode behave differently).\r
+\r
+There's clearly difference of opinion on what the defaults should be. So\r
+at the very least, we should make it easier to customize this.\r
+\r
+How about the following:\r
+\r
+  With no customization in place, the first time the user hits 'r',\r
+  notmuch prompts with something like:\r
+\r
+    Reply to all or sender only? [asAS?]:\r
+\r
+  Hitting '?' would the provide more instructions:\r
+\r
+    'a': Reply to all recipients for this reply.\r
+    's': Reply to sender-only for this reply.\r
+    'A': Reply to all recipients now and in the future (no questions asked)\r
+    'S': Reply to sender-only now and in the future (no questions asked)\r
+\r
+     Note: After setting a default behavior with 'A' or 'S' here, the\r
+     alternate behavior can still be obtained by initiating a reply with\r
+     'R' rather than 'r'.\r
+\r
+That would satisfy me as being sufficiently easy-to-use and sufficiently\r
+self-documenting.\r
+\r
+It also as the advantage of letting us make a change now without\r
+tripping up any users.\r
+\r
+I think the implementation should function by setting a single\r
+customize-based variable. But care should be taken such that the notmuch\r
+help modes still correctly describe what 'r' and 'R' do depending on how\r
+this variable is configured. My current approach of setting a preference\r
+by changing the keybindings yields correct documentation "for\r
+free". It's probably a little trickier to get that correct documentation\r
+with a single variable controlling things, but I hope it's not too hard.\r
+\r
+Anyone care to attempt an implementation of this?\r
+\r
+-Carl\r
+\r
+[*] Here's what I'm using now:\r
+\r
+(define-key notmuch-show-mode-map "r" 'notmuch-show-reply)\r
+(define-key notmuch-show-mode-map "R" 'notmuch-show-reply-sender)\r
+(define-key notmuch-search-mode-map "r" 'notmuch-search-reply-to-thread)\r
+(define-key notmuch-search-mode-map "R" 'notmuch-search-reply-to-thread-sender)\r
+\r
+--=-=-=\r
+Content-Type: application/pgp-signature\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v1.4.12 (GNU/Linux)\r
+\r
+iEYEARECAAYFAk/sm3QACgkQ6JDdNq8qSWh0+QCcCDHKkIVljuErChr6aGZaan8K\r
+dKcAnRXB2xsmq3u4UUu6y4RKpq08FkYP\r
+=+iKM\r
+-----END PGP SIGNATURE-----\r
+--=-=-=--\r