David Bremner <david@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 -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org