[notmuch] [PATCH 2/2] Save all attachments to a directory
Keith Amidon
camalot at picnicpark.org
Fri Dec 11 17:32:51 PST 2009
{-- Thu, 10 Dec 2009 16:57:01 -0800: Carl <cworth at cworth.org> wrote: --}
Carl> First, I'm not sure whether we need two different variations of
Carl> what's effectively the same operation here ("save all
Carl> attachments").
Yes, I agree it is an ugly solution. Thanks for not letting me get away
with it. :-)
Carl> What I would like is one command to save a single attachment,
Carl> and then one command to save all attachments. So if we assume
Carl> that the current 'w' keybinding is really for "write one
Carl> attachment" (with a lame implementation currently), and 'W' is
Carl> for "write all attachments", then I think I'd be OK with that.
What do you see as the "write one" behavior for a message with multiple
attachments? I think there needs to be some way to select the
attachment to be written. Maybe we use the prefix-argument for this so
that 'M-2 w' would write the second attachment, 'M-3 w' would write the
third attachment, etc. Since the default is 1, a plain 'w' would write
the first attachment which is the correct default for the single message
case. It's not the most discoverable approach, but it wouldn't be too
bad.
Carl> As for the changes we need here, the prompting for the directory
Carl> needs a string telling the user what's being prompted
Carl> for. Something like "Save all attachments to: ", which should
Carl> just be another argument to the interactive call, right?
Yes, you're right the current approach should have had a proper prompt.
I've been thinking about this though and I wonder if we should skip
separately prompting for the directory and instead do the following:
1) Have customizable "default save directory" both types of attachment
saving default to. Use this as the path part of the prompt for the
filename to which the attachment will be written.
2) After the user has adjusted the path as required, verify that the
full directory path exists and if not create it.
3) Use the same directory path as the default for any subsequent
attachments that are being saved.
This seems like it would lesson the number of keystrokes required for
at least some common cases.
Carl> Second, the command needs to provide a little bit of feedback as
Carl> to what was saved. I ended up running this command a couple of
Carl> times before I realized it was never going to save the inline
Carl> patch with no filename that I was looking at[*].
Carl> So it at least needs to message something like "N files written
Carl> to DIR" or so.
Sure, that's easy to add and makes a lot of sense. We should add
similar error reporting for other common error cases like selecting a
non-existing single attachment to save if we implement the
keystroke-based approach suggested above.
Carl> [*] So there's something else I think we need here. I was seeing
Carl> a patch in a message, but wanted to get it into a file before
Carl> piping it off to something, (so '|' didn't work). The patch
Carl> wasn't an attachment so 'w' didn't work as described above. I
Carl> tried using 'V' to view the raw message, but then found that the
Carl> MIME part I wanted was actually encoded as quoted-printable, so
Carl> just saving the raw message wasn't useful either.
I'm not sure it is the most usable solution, but I believe selecting the
text to save in the rendered message in the thread view and using "M-x
write-region" should handle this use case.
More information about the notmuch
mailing list