Quoth Mark Walters on Jan 18 at 12:40 am:
> 
> > Oof, sorry.  Two more tweaks that I really should have caught in the
> > previous version.  After that this gets my automatic +1.
> 
> Both fixed. I have also fixed the bug I mentioned (missing filename when
> "view" falls back on save); I couldn't make it work with the
> "no-default" option. However overriding mm-save-part with flet seems to
> do the trick.

Oh, indeed.  I'd foolishly assumed that when mm-display-part passed
the function mailcap-save-binary-file as the method to
mm-display-external that it would actually *use* that function, but
you're right that it uses mm-save-part.

> +(defun notmuch-show-view-part (message-id nth &optional filename content-type )
> +  (notmuch-with-temp-part-buffer message-id nth
> +    ;; set mm-inlined-types to nil to force an external viewer
> +    (let ((handle (mm-make-handle (current-buffer) (list content-type)))
> +         (mm-inlined-types nil))
> +      ;; We override mm-save-part as notmuch-show-save-part is better
> +      ;; since it offers the filename
> +      (flet ((mm-save-part (&rest args) (ignore)))
> +           (or (mm-display-part handle)
> +               (notmuch-show-save-part message-id nth filename content-type))))))
> 
> Is that a reasonable solution? 

It's *probably* safe to depend on the result of mm-display-part, but
you can avoid the question altogether by simply calling
notmuch-show-save-part from your flet mm-save-part.  E.g.,

(flet ((mm-save-part (&rest args) (notmuch-show-save-part 
                                   message-id nth filename content-type)))
  (mm-display-part handle))

(Yeah, flet indentation is lame.)

> Best wishes
> 
> Mark