2e/e7ac5291f3dd56b726b887f7aea8342d9aa21d

   1 Return-Path: <cworth@cworth.org>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id CE190431FB6\r
   6         for <notmuch@notmuchmail.org>; Thu, 28 Jun 2012 10:58:21 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: 0.01\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0.01 tagged_above=-999 required=5\r
  12         tests=[T_MIME_NO_TEXT=0.01] autolearn=disabled\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id Hk5TYPRccIE8 for <notmuch@notmuchmail.org>;\r
  16         Thu, 28 Jun 2012 10:58:21 -0700 (PDT)\r
  17 Received: from arlo.cworth.org (arlo.cworth.org [50.43.72.2])\r
  18         (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))\r
  19         (No client certificate requested)\r
  20         by olra.theworths.org (Postfix) with ESMTPS id F23A8431FAF\r
  21         for <notmuch@notmuchmail.org>; Thu, 28 Jun 2012 10:58:20 -0700 (PDT)\r
  22 Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
  23         by arlo.cworth.org (Postfix) with ESMTP id 9F46329A0D3;\r
  24         Thu, 28 Jun 2012 10:58:18 -0700 (PDT)\r
  25 Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
  26         id 4381664EB9; Thu, 28 Jun 2012 10:59:22 -0700 (PDT)\r
  27 From: Carl Worth <cworth@cworth.org>\r
  28 To: Philip Hands <phil@hands.com>, Jesse Rosenthal <jrosenthal@jhu.edu>,\r
  29         David Bremner <david@tethera.net>,\r
  30         Jameson Graef Rollins <jrollins@finestructure.net>, notmuch@notmuchmail.org\r
  31 Subject: Re: [PATCH] Restore original keybinding ('r' = reply-to-all)\r
  32 In-Reply-To: <87hatv4e37.fsf@poker.hands.com>\r
  33 References: <1340815565-21083-1-git-send-email-cworth@cworth.org>\r
  34         <87obo4zljq.fsf@servo.finestructure.net>\r
  35         <87hatwqoz9.fsf@maritornes.cs.unb.ca> <87ehozmpcq.fsf@jhu.edu>\r
  36         <87hatv4e37.fsf@poker.hands.com>\r
  37 User-Agent: Notmuch/0.13.1 (http://notmuchmail.org) Emacs/23.4.1\r
  38         (x86_64-pc-linux-gnu)\r
  39 Date: Thu, 28 Jun 2012 10:59:16 -0700\r
  40 Message-ID: <87y5n7z5aj.fsf@yoom.home.cworth.org>\r
  41 MIME-Version: 1.0\r
  42 Content-Type: multipart/signed; boundary="=-=-=";\r
  43         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  44 X-BeenThere: notmuch@notmuchmail.org\r
  45 X-Mailman-Version: 2.1.13\r
  46 Precedence: list\r
  47 List-Id: "Use and development of the notmuch mail system."\r
  48         <notmuch.notmuchmail.org>\r
  49 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  50         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  51 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  52 List-Post: <mailto:notmuch@notmuchmail.org>\r
  53 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  54 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  55         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  56 X-List-Received-Date: Thu, 28 Jun 2012 17:58:21 -0000\r
  57 \r
  58 --=-=-=\r
  59 \r
  60 Philip Hands <phil@hands.com> writes:\r
  61 > I find the change to the new (only reply to sender) behaviour serously\r
  62 > irritating, because it seems I cannot train myself to hit R all the time\r
  63 > (which is pretty much what I always want).\r
  64 \r
  65 I'm in a similar camp. I tried (and failed) to adopt to the current\r
  66 mode, (once I realized that the change had happened and that I had been\r
  67 mis-replying).\r
  68 \r
  69 I think part of the problem with training here is that if your mental\r
  70 model is "I generally want to reply to all, and exceptionally want to\r
  71 reply to only some" then the 'r == reply-to-sender' often does do what\r
  72 you want. That is, when the CC list is empty, reply-to-sender is no\r
  73 different than reply-to-all. So there's some mis-training that occurs,\r
  74 ('r' seems to do what I want). Worse, the results of the mis-training\r
  75 are hidden from the user, (since if the user didn't pay attention to the\r
  76 CC list before hitting 'r', the unintentional culling of recipients is\r
  77 hidden within the composition buffer).\r
  78 \r
  79 For me, personally, I tend to do a final examination of my message just\r
  80 before sending. This is a quick scan to look for typos, make sure my\r
  81 message is clear, etc. During part of this scan, it's also natural for\r
  82 me to ensure that there isn't anyone in the recipient list that\r
  83 shouldn't be receiving the message. If I do decide to remove some\r
  84 recipients from my message, this is a natural time for me to do it, (or\r
  85 perhaps earlier, during composition, when first writing something\r
  86 sensitive).\r
  87 \r
  88 So, for me, making a decision *before* writing anything doesn't fit my\r
  89 mental model, (I'll often change the tone of my message while composing,\r
  90 and in ways that the recipient list might change).\r
  91 \r
  92 I also find reply-to-sender-only too limiting of an operation, (compared\r
  93 to reply-to-all followed by header editing). For example, sometimes I\r
  94 might want to drop some smaller subset of recipients from my reply.\r
  95 \r
  96 My workflow is definitely influenced my the habits of coworkers in my\r
  97 corporate environment. While there are many mailing-list addresses,\r
  98 there are often large threads involving ad-hoc recipient lists. And as\r
  99 conversations go, some groups of individuals needs to be added or\r
 100 removed from the discussion. Header editing works for that, in a way\r
 101 that reply-to-sender doesn't help.\r
 102 \r
 103 > On the other hand, I'm perfectly capable of customising this, but have\r
 104 > something of a fetish for at least trying to live with defaults for a\r
 105 > period, so it's my own fault for putting up with it.\r
 106 \r
 107 I'm obviously capable of making a customization as well, (and have done\r
 108 so). The current mechanism[*] I'm using for this customization is\r
 109 particularly clumsy, (it's not exposed in the customize buffer, it\r
 110 requires the user to know the names of internal objects like\r
 111 notmuch-show-mode-map and notmuch-search-reply-to-thread-sender), and it\r
 112 requires the user to change 4 settings, (in two separate places), in\r
 113 order to get a consistent experience, (so it would be easy to\r
 114 accidentally make search-mode and show-mode behave differently).\r
 115 \r
 116 There's clearly difference of opinion on what the defaults should be. So\r
 117 at the very least, we should make it easier to customize this.\r
 118 \r
 119 How about the following:\r
 120 \r
 121   With no customization in place, the first time the user hits 'r',\r
 122   notmuch prompts with something like:\r
 123 \r
 124     Reply to all or sender only? [asAS?]:\r
 125 \r
 126   Hitting '?' would the provide more instructions:\r
 127 \r
 128     'a': Reply to all recipients for this reply.\r
 129     's': Reply to sender-only for this reply.\r
 130     'A': Reply to all recipients now and in the future (no questions asked)\r
 131     'S': Reply to sender-only now and in the future (no questions asked)\r
 132 \r
 133      Note: After setting a default behavior with 'A' or 'S' here, the\r
 134      alternate behavior can still be obtained by initiating a reply with\r
 135      'R' rather than 'r'.\r
 136 \r
 137 That would satisfy me as being sufficiently easy-to-use and sufficiently\r
 138 self-documenting.\r
 139 \r
 140 It also as the advantage of letting us make a change now without\r
 141 tripping up any users.\r
 142 \r
 143 I think the implementation should function by setting a single\r
 144 customize-based variable. But care should be taken such that the notmuch\r
 145 help modes still correctly describe what 'r' and 'R' do depending on how\r
 146 this variable is configured. My current approach of setting a preference\r
 147 by changing the keybindings yields correct documentation "for\r
 148 free". It's probably a little trickier to get that correct documentation\r
 149 with a single variable controlling things, but I hope it's not too hard.\r
 150 \r
 151 Anyone care to attempt an implementation of this?\r
 152 \r
 153 -Carl\r
 154 \r
 155 [*] Here's what I'm using now:\r
 156 \r
 157 (define-key notmuch-show-mode-map "r" 'notmuch-show-reply)\r
 158 (define-key notmuch-show-mode-map "R" 'notmuch-show-reply-sender)\r
 159 (define-key notmuch-search-mode-map "r" 'notmuch-search-reply-to-thread)\r
 160 (define-key notmuch-search-mode-map "R" 'notmuch-search-reply-to-thread-sender)\r
 161 \r
 162 --=-=-=\r
 163 Content-Type: application/pgp-signature\r
 164 \r
 165 -----BEGIN PGP SIGNATURE-----\r
 166 Version: GnuPG v1.4.12 (GNU/Linux)\r
 167 \r
 168 iEYEARECAAYFAk/sm3QACgkQ6JDdNq8qSWh0+QCcCDHKkIVljuErChr6aGZaan8K\r
 169 dKcAnRXB2xsmq3u4UUu6y4RKpq08FkYP\r
 170 =+iKM\r
 171 -----END PGP SIGNATURE-----\r
 172 --=-=-=--\r