[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