Date: Sun, 26 May 2013 02:36:27 -0400
From: Austin Clements <amdragon@MIT.EDU>
To: Mark Walters <markwalters1009@gmail.com>
Subject: Re: [PATCH] emacs: Don't override mm-show-part in
	notmuch-show-view-part
Message-ID: <20130526063627.GQ5999@mit.edu>
References: <20130520170439.GG5999@mit.edu>
	<1369080503-6866-1-git-send-email-amdragon@mit.edu>
	<8761ycc19t.fsf@qmul.ac.uk> <87fvxguoxm.fsf@qmul.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87fvxguoxm.fsf@qmul.ac.uk>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: notmuch@notmuchmail.org
Precedence: list

Quoth Mark Walters on May 21 at  8:13 pm:
> 
> On Tue, 21 May 2013, Mark Walters <markwalters1009@gmail.com> wrote:
> > Hi
> >
> >> Previously, notmuch-show-view-part overrode the function binding of
> >> mm-show-part to redirect it to notmuch-show-save-part to get notmuch's
> >> default file name handling in case mm-display-part decided to fall
> >> back to saving the part.  In addition to being messy, this depended on
> >> the now-deprecated dynamic binding behavior of flet.
> >>
> >> This patch removes the mm-show-part override in favor of passing the
> >> file name in to mm-show-part the way it expects, so we get its default
> >> file name handling.  It's not clear why we didn't do this before;
> >> mm-show-part has supported default file names since at least Emacs
> >> 23.1.
> >
> > The new code is much simpler (and nicer). However, one small annoyance
> > is it makes notmuch-show-save-part and notmuch-show-view-part behave
> > differently on parts which can only be saved (eg
> > application/octet-stream): view-part (ie mm-save-part) offers the
> > current directory (where emacs was started) whereas the notmuch
> > save-part explicitly offers mailcap-download-directory or ~/. I have no
> > preference which is used but think they should be the same. Perhaps
> > notmuch-show-save-part could just call mm-save-part? I have tried that
> > and the tests pass. (If we can do that I think the whole part button handling
> > stuff could be unified/simplified significantly)
> 
> Here is the code I was using to try using mm-save-part rather than our
> own version. I don't know why we have our own version: this does pass
> the tests and seems to work (though as mentioned above the semantics of
> which default path is used are different)

I think this is a good idea.  I'm putting together a patch that cleans
up and simplifies all of the part button handling code by taking
better advantage of mm.  I should have it ready in the next few days.

> Best wishes
> 
> Mark
> 
> ---
>  emacs/notmuch-show.el |   13 ++++---------
>  1 files changed, 4 insertions(+), 9 deletions(-)
> 
> diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
> index 45039bd..a63b857 100644
> --- a/emacs/notmuch-show.el
> +++ b/emacs/notmuch-show.el
> @@ -516,15 +516,10 @@ message at DEPTH in the current thread."
>  
>  (defun notmuch-show-save-part (message-id nth &optional filename content-type)
>    (notmuch-with-temp-part-buffer message-id nth
> -    (let ((file (read-file-name
> -		 "Filename to save as: "
> -		 (or mailcap-download-directory "~/")
> -		 nil nil
> -		 filename)))
> -      ;; Don't re-compress .gz & al.  Arguably we should make
> -      ;; `file-name-handler-alist' nil, but that would chop
> -      ;; ange-ftp, which is reasonable to use here.
> -      (mm-write-region (point-min) (point-max) file nil nil nil 'no-conversion t))))
> +    (let* ((disposition (if filename `(attachment (filename . ,filename))))
> +	   (handle (mm-make-handle (current-buffer) (list content-type)
> +				   nil nil disposition)))
> +      (mm-save-part handle))))
>  
>  (defun notmuch-show-view-part (message-id nth &optional filename content-type )
>    (notmuch-with-temp-part-buffer message-id nth