Quoth Mark Walters on Jan 18 at 10:46 am:
> 
> > > +(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))
> 
> Unfortunately that does not work since mm-display-part has a local
> variable "filename".  I could copy the variables to some notmuch
> prefixed variables but maybe there is some obvious "quoting" to avoid
> the problem? (I can't easily check now as the gnu site is closed for the
> day.)

Arrrg, dynamic scoping.  Well, you can

;; Lexically bind everything we need in mm-save-part to prevent
;; potential dynamic shadowing.
(lexical-let ((message-id message-id)
              (nth nth)
              (filename filename)
              (content-type content-type))
  (flet ((mm-save-part (&rest args) (notmuch-show-save-part 
                                     message-id nth filename content-type)))
    (mm-display-part handle)))

Or you could just, y'know, do what were doing.