From: Aaron Ecay <aaronecay@gmail.com>
To: Chris Gray <chrismgray@gmail.com>, David Edmondson <dme@dme.org>,
	notmuch@notmuchmail.org
Subject: Re: [RFC][PATCH] emacs: Provide scaffolding so that the new `shr'
	HTML renderer can run.
In-Reply-To: <8762hbkas3.fsf@gmail.com>
References: <1324309559-7993-1-git-send-email-dme@dme.org>
	<8762hbkas3.fsf@gmail.com>
User-Agent: Notmuch/0.10.1+56~gd709fd6 (http://notmuchmail.org)
	Emacs/24.0.92.3 (i386-apple-darwin10.8.0)
Date: Tue, 20 Dec 2011 03:40:44 -0500
Message-ID: <m239cfmy9f.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: list

On Mon, 19 Dec 2011 23:38:36 -0700, Chris Gray <chrismgray@gmail.com> wrote:
> This is working around a bug in gnus.

Arguably this is true, but the real =E2=80=9Cbug=E2=80=9D (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=E2=80=99t I think it=E2=80=99s 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=E2=80=99t something we should be
    seeking to perpetuate.

--=20
Aaron Ecay