9d/769e1327b758c25f656d37e74b30ed4332ea86

   1 Return-Path: <camalot@picnicpark.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 2F9B3431FBD\r
   6         for <notmuch@notmuchmail.org>; Fri, 11 Dec 2009 17:32:57 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 Received: from olra.theworths.org ([127.0.0.1])\r
   9         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  10         with ESMTP id KbcXwB2Mvpj4 for <notmuch@notmuchmail.org>;\r
  11         Fri, 11 Dec 2009 17:32:56 -0800 (PST)\r
  12 Received: from picnicpark.org (picnicpark.org [130.94.181.238])\r
  13         by olra.theworths.org (Postfix) with ESMTP id 07EB4431FAE\r
  14         for <notmuch@notmuchmail.org>; Fri, 11 Dec 2009 17:32:55 -0800 (PST)\r
  15 Received: (qmail 29714 invoked by uid 13806); 12 Dec 2009 01:32:52 -0000\r
  16 Received: from unknown (HELO gw.picnicpark.org) ([76.210.240.177])\r
  17         (envelope-sender <camalot@picnicpark.org>)\r
  18         by 130.94.181.238 (qmail-ldap-1.03) with SMTP\r
  19         for <cworth@cworth.org>; 12 Dec 2009 01:32:52 -0000\r
  20 Received: from friend.picnicpark.org.picnicpark.org (friend.picnicpark.org\r
  21         [192.168.35.1])\r
  22         by gw.picnicpark.org (Postfix) with ESMTP id 051E5550094;\r
  23         Fri, 11 Dec 2009 17:32:51 -0800 (PST)\r
  24 From: Keith Amidon <camalot@picnicpark.org>\r
  25 To: Carl Worth <cworth@cworth.org>\r
  26 Organization: picnicpark.org\r
  27 References: <1260053640-10034-1-git-send-email-keith@nicira.com>\r
  28         <1260053640-10034-2-git-send-email-keith@nicira.com>\r
  29         <1260053640-10034-3-git-send-email-keith@nicira.com>\r
  30         <878wda49b6.fsf@yoom.home.cworth.org>\r
  31 Date: Fri, 11 Dec 2009 17:32:51 -0800\r
  32 In-Reply-To: <878wda49b6.fsf@yoom.home.cworth.org> (Carl Worth's message of\r
  33         "Thu, 10 Dec 2009 16:57:01 -0800")\r
  34 Message-ID: <873a3hou2k.fsf@friend.picnicpark.org>\r
  35 User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.1 (gnu/linux)\r
  36 MIME-Version: 1.0\r
  37 Content-Type: text/plain; charset=us-ascii\r
  38 Cc: Keith Amidon <keith@nicira.com>, notmuch@notmuchmail.org\r
  39 Subject: Re: [notmuch] [PATCH 2/2] Save all attachments to a directory\r
  40 X-BeenThere: notmuch@notmuchmail.org\r
  41 X-Mailman-Version: 2.1.12\r
  42 Precedence: list\r
  43 List-Id: "Use and development of the notmuch mail system."\r
  44         <notmuch.notmuchmail.org>\r
  45 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  46         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  47 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  48 List-Post: <mailto:notmuch@notmuchmail.org>\r
  49 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  50 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  51         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  52 X-List-Received-Date: Sat, 12 Dec 2009 01:32:57 -0000\r
  53 \r
  54 {-- Thu, 10 Dec 2009 16:57:01 -0800: Carl <cworth@cworth.org> wrote: --}\r
  55 \r
  56   Carl> First, I'm not sure whether we need two different variations of\r
  57   Carl> what's effectively the same operation here ("save all\r
  58   Carl> attachments").\r
  59 \r
  60 Yes, I agree it is an ugly solution.  Thanks for not letting me get away\r
  61 with it.  :-)\r
  62 \r
  63   Carl> What I would like is one command to save a single attachment,\r
  64   Carl> and then one command to save all attachments. So if we assume\r
  65   Carl> that the current 'w' keybinding is really for "write one\r
  66   Carl> attachment" (with a lame implementation currently), and 'W' is\r
  67   Carl> for "write all attachments", then I think I'd be OK with that.\r
  68 \r
  69 What do you see as the "write one" behavior for a message with multiple\r
  70 attachments?  I think there needs to be some way to select the\r
  71 attachment to be written.  Maybe we use the prefix-argument for this so\r
  72 that 'M-2 w' would write the second attachment, 'M-3 w' would write the\r
  73 third attachment, etc.  Since the default is 1, a plain 'w' would write\r
  74 the first attachment which is the correct default for the single message\r
  75 case.  It's not the most discoverable approach, but it wouldn't be too\r
  76 bad.  \r
  77 \r
  78   Carl> As for the changes we need here, the prompting for the directory\r
  79   Carl> needs a string telling the user what's being prompted\r
  80   Carl> for. Something like "Save all attachments to: ", which should\r
  81   Carl> just be another argument to the interactive call, right?\r
  82 \r
  83 Yes, you're right the current approach should have had a proper prompt.\r
  84 I've been thinking about this though and I wonder if we should skip\r
  85 separately prompting for the directory and instead do the following:\r
  86 \r
  87 1) Have customizable "default save directory" both types of attachment\r
  88    saving default to.  Use this as the path part of the prompt for the\r
  89    filename to which the attachment will be written.\r
  90 2) After the user has adjusted the path as required, verify that the\r
  91    full directory path exists and if not create it.\r
  92 3) Use the same directory path as the default for any subsequent\r
  93    attachments that are being saved.\r
  94 \r
  95 This seems like it would lesson the number of keystrokes required for\r
  96 at least some common cases.\r
  97 \r
  98   Carl> Second, the command needs to provide a little bit of feedback as\r
  99   Carl> to what was saved. I ended up running this command a couple of\r
 100   Carl> times before I realized it was never going to save the inline\r
 101   Carl> patch with no filename that I was looking at[*].\r
 102 \r
 103   Carl> So it at least needs to message something like "N files written\r
 104   Carl> to DIR" or so.\r
 105 \r
 106 Sure, that's easy to add and makes a lot of sense.  We should add\r
 107 similar error reporting for other common error cases like selecting a\r
 108 non-existing single attachment to save if we implement the\r
 109 keystroke-based approach suggested above.\r
 110 \r
 111   Carl> [*] So there's something else I think we need here. I was seeing\r
 112   Carl> a patch in a message, but wanted to get it into a file before\r
 113   Carl> piping it off to something, (so '|' didn't work). The patch\r
 114   Carl> wasn't an attachment so 'w' didn't work as described above. I\r
 115   Carl> tried using 'V' to view the raw message, but then found that the\r
 116   Carl> MIME part I wanted was actually encoded as quoted-printable, so\r
 117   Carl> just saving the raw message wasn't useful either.\r
 118 \r
 119 I'm not sure it is the most usable solution, but I believe selecting the\r
 120 text to save in the rendered message in the thread view and using "M-x\r
 121 write-region" should handle this use case.\r
 122 \r