David Bremner <da...@tethera.net> writes: > I should have been more precise. I'm calling it indirectly via > mm-display-part, which is useful in the case where someone attaches a > message/rfc822 part to their message. In principle notmuch can (and in > the general case does) render the part directly, but in certain odd > fall-back cases it is handy to give a visual representation of the part > in the buffer without parsing etc.. ourselves. So the user does have a > mail reader, namely notmuch. In fact I can almost make it work by > forcing the buffer back into notmuch-show-mode after calling > mm-display-part, but that has some side-effects I'd prefer to avoid.
Yes, that was what I was thinking about -- the rendered embedded message can't be easily interacted with without the mail reader being able to hook into the rendering. I mean, it's a kinda semi-recursive thing: You want to be able to use (some of) the mail reader's commands to respond to the embedded message. Which is why `mm-inline-message' calls the Gnus functions here. But perhaps the function should be rewritten to call a (say) `mm-inline-message-setup-function', bound by the caller? Then both Gnus and notmuch could use the function. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no _______________________________________________ notmuch mailing list -- firstname.lastname@example.org To unsubscribe send an email to notmuch-le...@notmuchmail.org