From: Keith Amidon <camalot@picnicpark.org>
To: Carl Worth <cworth@cworth.org>
Organization: picnicpark.org
References: <1260053640-10034-1-git-send-email-keith@nicira.com>
	<1260053640-10034-2-git-send-email-keith@nicira.com>
	<1260053640-10034-3-git-send-email-keith@nicira.com>
	<878wda49b6.fsf@yoom.home.cworth.org>
Date: Fri, 11 Dec 2009 17:32:51 -0800
In-Reply-To: <878wda49b6.fsf@yoom.home.cworth.org> (Carl Worth's message of
	"Thu, 10 Dec 2009 16:57:01 -0800")
Message-ID: <873a3hou2k.fsf@friend.picnicpark.org>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Keith Amidon <keith@nicira.com>, notmuch@notmuchmail.org
Subject: Re: [notmuch] [PATCH 2/2] Save all attachments to a directory
Precedence: list

{-- Thu, 10 Dec 2009 16:57:01 -0800: Carl <cworth@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.