47/6ca28dba437313ff5dad4740149d4cf06018ee

   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 92EAF431FBC\r
   6         for <notmuch@notmuchmail.org>; Tue, 23 Feb 2010 11:12:39 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -1.951\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5\r
  12         tests=[ALL_TRUSTED=-1.8, AWL=-0.152, BAYES_50=0.001] autolearn=ham\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 lkmoVg8bc1LQ; Tue, 23 Feb 2010 11:12:38 -0800 (PST)\r
  16 Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
  17         by olra.theworths.org (Postfix) with ESMTP id C62C3431FAE;\r
  18         Tue, 23 Feb 2010 11:12:38 -0800 (PST)\r
  19 Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
  20         id 1EF8725427B; Tue, 23 Feb 2010 11:12:37 -0800 (PST)\r
  21 From: Carl Worth <cworth@cworth.org>\r
  22 To: camalot@picnicpark.org, notmuch@notmuchmail.org\r
  23 In-Reply-To: <1260814438-4195-2-git-send-email-camalot@picnicpark.org>\r
  24 References: <87my1m323m.fsf@yoom.home.cworth.org>\r
  25         <1260814438-4195-1-git-send-email-camalot@picnicpark.org>\r
  26         <1260814438-4195-2-git-send-email-camalot@picnicpark.org>\r
  27 Date: Tue, 23 Feb 2010 11:12:36 -0800\r
  28 Message-ID: <87d3zvwyu3.fsf@yoom.home.cworth.org>\r
  29 MIME-Version: 1.0\r
  30 Content-Type: multipart/signed; boundary="=-=-=";\r
  31         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  32 Cc: Keith Amidon <keith@nicira.com>\r
  33 Subject: Re: [notmuch] [PATCH] Rework saving of attachments.\r
  34 X-BeenThere: notmuch@notmuchmail.org\r
  35 X-Mailman-Version: 2.1.13\r
  36 Precedence: list\r
  37 List-Id: "Use and development of the notmuch mail system."\r
  38         <notmuch.notmuchmail.org>\r
  39 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  40         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  41 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  42 List-Post: <mailto:notmuch@notmuchmail.org>\r
  43 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  44 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  45         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  46 X-List-Received-Date: Tue, 23 Feb 2010 19:12:39 -0000\r
  47 \r
  48 --=-=-=\r
  49 \r
  50 On Mon, 14 Dec 2009 10:13:58 -0800, camalot@picnicpark.org wrote:\r
  51 > From: Keith Amidon <keith@nicira.com>\r
  52 \r
  53 Hi Keith,\r
  54 \r
  55 I apologize for the extraordinarly-late review, but here it is...\r
  56 \r
  57 I tried this patch out, wanted to like it, and almost pushed it out, but\r
  58 I decided against it in its current form. Here are some thoughts:\r
  59 \r
  60 1. The commit message ("rework saving of attachments") is not\r
  61    adequate. It doesn't actually say what the commit does, (how can I\r
  62    test whether things have been reworked?). If the vagueness of the\r
  63    message is because the commit is changing several different aspects\r
  64    of behavior, then I would argue that the commit should be split up\r
  65    into separate pieces.\r
  66 \r
  67 2. A binding to save a single attachment (with only a prefix argument to\r
  68    select which) just isn't usable. First, there's nothing in the UI to\r
  69    indicate the appropriate numbers to pass as the prefix argument,\r
  70    (other than manually counting the attachments). And second, the\r
  71    functionality is simply too hidden and non-obvious. This is most\r
  72    dangerous because in the common case of a single attachment, the 'w'\r
  73    binding will seem to be saving all attachments setting up confusion\r
  74    if the user tries to save multiple attachments with this same\r
  75    keybinding.\r
  76 \r
  77    Now, having a function to save a single attachment is just fine,\r
  78    (leaving someone else to hook up a binding to a particular button,\r
  79    say). So I'd accept a patch that added that, but didn't add a direct\r
  80    key-binding for it.\r
  81 \r
  82 3. For saving multiple attachments, the feature I'd really like to see\r
  83    is the ability to specify a single directory and have all the\r
  84    attachments saved there.\r
  85 \r
  86 Obviously, this third feature is just something different than what the\r
  87 patch does, so not necessarily a reason to reject the patch. So what is\r
  88 it that the patch actually does again?\r
  89 \r
  90 I think the big advantage of the patch is getting rid of the initial\r
  91 prompting "save this attachment (foo)?". It occurs to me that a simpler\r
  92 way to get rid of that would be to simply not ask that question when the\r
  93 user hits 'w' and there *is* only a single attachment. Then, with\r
  94 multiple attachments, 'w' could prompt in turn as currently.\r
  95 \r
  96 That would leave open the ability to use 'W' for a command to write all\r
  97 attachments to a particular directory.\r
  98 \r
  99 So that's one idea, at least. What do you think?\r
 100 \r
 101 -Carl\r
 102 \r
 103 --=-=-=\r
 104 Content-Type: application/pgp-signature\r
 105 \r
 106 -----BEGIN PGP SIGNATURE-----\r
 107 Version: GnuPG v1.4.10 (GNU/Linux)\r
 108 \r
 109 iD8DBQFLhCik6JDdNq8qSWgRAhqXAKCIbMR9jYdOuK4tKPEkPrZCGUXT0ACfXFhD\r
 110 gx1I/+4jTl1VWzX7rci/8mQ=\r
 111 =Rld/\r
 112 -----END PGP SIGNATURE-----\r
 113 --=-=-=--\r