[RFC][PATCH] emacs: Provide scaffolding so that the new `shr' HTML renderer can run.

Aaron Ecay aaronecay at gmail.com
Tue Dec 20 00:40:44 PST 2011


On Mon, 19 Dec 2011 23:38:36 -0700, Chris Gray <chrismgray at gmail.com> wrote:
> This is working around a bug in gnus.

Arguably this is true, but the real “bug” (conceptual error) is that the
MIME handling libraries and gnus are a little too tightly coupled.  Why
should notmuch users have to load gnus (gnus-art.el does (require 'gnus),
which brings in tens of thousands of lines of Elisp)[1], or customize
gnus-* variables to use general-purpose MIME viewing, HTML rendering
facilities?

The best GNUS-side solution would be to make mm-shr GNUS-agnostic, and
probably to introduce shr-{inhibit,blocked}-images as customizable
variables in their own right (which could inherit their values from the
gnus-* versions under the right circumstances).

I hope that the GNUS folks are receptive to this approach, but if they
aren’t I think it’s better for notmuch to not go the way of requiring
that GNUS be loaded to function.

Aaron

[1] I see that (featurep 'gnus) returns t for me, so that horse is
    already out of the barn.  But it isn’t something we should be
    seeking to perpetuate.

-- 
Aaron Ecay


More information about the notmuch mailing list