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.