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 7756A431FBC
\r
6 for <notmuch@notmuchmail.org>; Wed, 24 Feb 2010 06:57:54 -0800 (PST)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
11 X-Spam-Status: No, score=-0.239 tagged_above=-999 required=5
\r
12 tests=[AWL=-0.054, BAYES_40=-0.185] autolearn=unavailable
\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 Ki-Nt610dNDX for <notmuch@notmuchmail.org>;
\r
16 Wed, 24 Feb 2010 06:57:52 -0800 (PST)
\r
17 Received: from picnicpark.org (picnicpark.org [130.94.181.238])
\r
18 by olra.theworths.org (Postfix) with ESMTP id 2647A431FAE
\r
19 for <notmuch@notmuchmail.org>; Wed, 24 Feb 2010 06:57:52 -0800 (PST)
\r
20 Received: (qmail 35895 invoked by uid 13806); 24 Feb 2010 14:57:49 -0000
\r
21 Received: from unknown (HELO gw.picnicpark.org) ([76.210.240.177])
\r
22 (envelope-sender <camalot@picnicpark.org>)
\r
23 by 130.94.181.238 (qmail-ldap-1.03) with SMTP
\r
24 for <cworth@cworth.org>; 24 Feb 2010 14:57:49 -0000
\r
25 Received: from friend.picnicpark.org.picnicpark.org (friend.picnicpark.org
\r
27 by gw.picnicpark.org (Postfix) with ESMTP id 01A915507C0;
\r
28 Wed, 24 Feb 2010 06:57:48 -0800 (PST)
\r
29 From: Keith Amidon <camalot@picnicpark.org>
\r
30 To: Carl Worth <cworth@cworth.org>
\r
31 Organization: picnicpark.org
\r
32 References: <87my1m323m.fsf@yoom.home.cworth.org>
\r
33 <1260814438-4195-1-git-send-email-camalot@picnicpark.org>
\r
34 <1260814438-4195-2-git-send-email-camalot@picnicpark.org>
\r
35 <87d3zvwyu3.fsf@yoom.home.cworth.org>
\r
36 Date: Wed, 24 Feb 2010 06:57:48 -0800
\r
37 In-Reply-To: <87d3zvwyu3.fsf@yoom.home.cworth.org> (Carl Worth's message of
\r
38 "Tue, 23 Feb 2010 11:12:36 -0800")
\r
39 Message-ID: <87mxyyptoz.fsf@friend.picnicpark.org>
\r
40 User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.1 (gnu/linux)
\r
42 Content-Type: text/plain; charset=us-ascii
\r
43 Cc: notmuch@notmuchmail.org
\r
44 Subject: Re: [notmuch] [PATCH] Rework saving of attachments.
\r
45 X-BeenThere: notmuch@notmuchmail.org
\r
46 X-Mailman-Version: 2.1.13
\r
48 List-Id: "Use and development of the notmuch mail system."
\r
49 <notmuch.notmuchmail.org>
\r
50 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
51 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
52 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
53 List-Post: <mailto:notmuch@notmuchmail.org>
\r
54 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
55 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
56 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
57 X-List-Received-Date: Wed, 24 Feb 2010 14:57:54 -0000
\r
59 Resending to the list as well as just Carl...
\r
61 {-- Tue, 23 Feb 2010 11:12:36 -0800: Carl <cworth@cworth.org> wrote: --}
\r
62 Carl> I apologize for the extraordinarly-late review, but here it
\r
65 No problem at all. You're updates on status have been sufficient to
\r
66 convince me you were making progress and would get to everything
\r
67 eventually and I've not exactly had any significant time to be playing
\r
68 with notmuch code anyway. :-)
\r
70 Carl> I tried this patch out, wanted to like it, and almost pushed it
\r
71 Carl> out, but I decided against it in its current form. Here are some
\r
74 Carl> 1. The commit message ("rework saving of attachments") is not
\r
77 Sure, I can make more granular commits. Much of the work in this one
\r
78 was inter-related in that my goal for the behavior couldn't be tested
\r
79 until most of the work was done and I didn't take much care to commit
\r
80 interim steps due to an over-eagerness to complete the changes. Easily
\r
83 Carl> 2. A binding to save a single attachment (with only a prefix
\r
84 Carl> argument to select which) just isn't usable.
\r
86 Yes, I agree the current implementation for the save single attachment
\r
89 Carl> First, there's nothing in the UI to indicate the appropriate
\r
90 Carl> numbers to pass as the prefix argument, (other than manually
\r
91 Carl> counting the attachments).
\r
93 This is the real problem in my opinion. My plan, which I've had no time
\r
94 to implement, was to do something similar to what Gnus does; make a
\r
95 button for each part and in the button text include the number of each
\r
96 part. This way the user would no longer have to manually count.
\r
98 Carl> And second, the functionality is simply too hidden and
\r
99 Carl> non-obvious. This is most dangerous because in the common case
\r
100 Carl> of a single attachment, the 'w' binding will seem to be saving
\r
101 Carl> all attachments setting up confusion if the user tries to save
\r
102 Carl> multiple attachments with this same keybinding.
\r
104 Carl> Now, having a function to save a single attachment is just
\r
105 Carl> fine, (leaving someone else to hook up a binding to a particular
\r
106 Carl> button, say). So I'd accept a patch that added that, but didn't
\r
107 Carl> add a direct key-binding for it.
\r
109 I personally think that there should be a key-binding that allows saving
\r
110 individual attachments and doesn't require navigating to a button in the
\r
111 message and then doing something. There are key-bindings in Gnus to do
\r
112 this that I use all the time and I think notmuch should support
\r
113 something similar. Maybe the right approach is to combine both
\r
114 functions on a single key-binding for example if no prefix argument is
\r
115 given all attachments are saved and a prefix selects the specific
\r
118 Carl> 3. For saving multiple attachments, the feature I'd really like
\r
119 Carl> to see is the ability to specify a single directory and have all
\r
120 Carl> the attachments saved there.
\r
122 I think the current code does support this functionality, although it
\r
123 may not be completely obvious. It adds a default directory in which to
\r
124 save attachments (notmuch-default-save-dir). When you type 'W' to save
\r
125 all attachments it prompts for the location to save the first attachment
\r
126 with a path built from the combination of notmuch-default-save-dir and
\r
127 the filename or description of the attachment. You can edit this path
\r
128 to your heart's content. Any subsequent attachments to be saved will
\r
129 default to the directory into which you saved the most recent
\r
132 In use, if you want all attachments saved to the default directory with
\r
133 their default filenames all you have to do is hit 'W' followed by one
\r
134 carriage return per attachment. If you want all of them saved to the
\r
135 same directory but different from the default save directory you hit 'W'
\r
136 edit the first path, then hit enter for each subsequent attachment. The
\r
137 changes support creating the destination directory path if it is not
\r
140 Carl> Obviously, this third feature is just something different than
\r
141 Carl> what the patch does, so not necessarily a reason to reject the
\r
142 Carl> patch. So what is it that the patch actually does again?
\r
144 Carl> I think the big advantage of the patch is getting rid of the
\r
145 Carl> initial prompting "save this attachment (foo)?". It occurs to me
\r
146 Carl> that a simpler way to get rid of that would be to simply not ask
\r
147 Carl> that question when the user hits 'w' and there *is* only a
\r
148 Carl> single attachment. Then, with multiple attachments, 'w' could
\r
149 Carl> prompt in turn as currently.
\r
151 In my mind the key advantage of the patch was the much improved behavior
\r
152 of the 'W' keybinding, described above. Maybe that just wasn't obvious?
\r
154 Carl> That would leave open the ability to use 'W' for a command to
\r
155 Carl> write all attachments to a particular directory.
\r
157 For this are you imagining that the user would first be prompted for the
\r
158 directory in which to save the attachments and then all attachments
\r
159 would be saved with some set of default names and no need for further
\r
160 keypresses from the users? I thought about doing something similar but
\r
161 was worried that there might be situations in which the resulting
\r
162 filenames to which the attachments were saved might not be easy for the
\r
163 user to correlate back to what they thought they were saving from within
\r
166 If we combined the behavior of the current code into a single 'w'
\r
167 key-binding that accomplished the behavior of both 'w' and 'W' in this
\r
168 patch it would leave 'W' open for something like this if you think it
\r
169 would be a significant convenience.
\r
171 Carl> So that's one idea, at least. What do you think?
\r
173 I've probably said enough on that score already. :-)
\r
projects / notmuch-archives.git / blob