From: Chris Gray <chrismgray@gmail.com>
To: notmuch@notmuchmail.org
Subject: Re: [RFC][PATCH] emacs: Provide scaffolding so that the new `shr'
	HTML renderer can run.
In-Reply-To: <m239cfmy9f.fsf@gmail.com>
References: <1324309559-7993-1-git-send-email-dme@dme.org>
	<8762hbkas3.fsf@gmail.com> <m239cfmy9f.fsf@gmail.com>
User-Agent: Notmuch/0.10.2+95~g2eb2694 (http://notmuchmail.org)
	Emacs/24.0.92.1 (i486-pc-linux-gnu)
Date: Tue, 20 Dec 2011 10:06:31 -0700
Message-ID: <87wr9ri354.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: list

On Tue, 20 Dec 2011 03:40:44 -0500, Aaron Ecay <aaronecay@gmail.com> wrote:
> On Mon, 19 Dec 2011 23:38:36 -0700, Chris Gray <chrismgray@gmail.com> wro=
te:
> > This is working around a bug in gnus.
>=20
> Arguably this is true, but the real =E2=80=9Cbug=E2=80=9D (conceptual err=
or) 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?

I agree with this 100%.  However, we should still try to use emacs
coding best-practices, which means not defining variables that are
defined in other packages.  Unfortunately, getting the gnus folks to fix
their library might take a while, so it might be okay to relax those
best-practices while we wait, but we should be aware of the fact that
that's what we're doing.

Cheers,
Chris