From: Pieter Praet <pieter@praet.org>
To: Aaron Ecay <aaronecay@gmail.com>, David Edmondson <dme@dme.org>
Subject: Re: [PATCH] v2 [RFC] emacs: merge overhauled
	`notmuch-cycle-notmuch-buffers' into `notmuch'
In-Reply-To: <m262g864dz.fsf@wal122.wireless-pennnet.upenn.edu>
References: <87r4yza95m.fsf@praet.org>
	<1326732415-21894-1-git-send-email-pieter@praet.org>
	<cun39bftw9b.fsf@hotblack-desiato.hh.sledj.net>
	<87fwfd8h0i.fsf@praet.org>
	<cunk44pmi7k.fsf@hotblack-desiato.hh.sledj.net>
	<87obu19pfo.fsf@praet.org>
	<cunhaztmalq.fsf@hotblack-desiato.hh.sledj.net>
	<cunboq1mad1.fsf@hotblack-desiato.hh.sledj.net>
	<87sjjdp1f1.fsf@praet.org>
	<m262g864dz.fsf@wal122.wireless-pennnet.upenn.edu>
User-Agent: Notmuch/0.11+99~gab86e73 (http://notmuchmail.org) Emacs/23.3.1
	(x86_64-unknown-linux-gnu)
Date: Thu, 19 Jan 2012 20:13:53 +0100
Message-ID: <87hazro68e.fsf@praet.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Notmuch Mail <notmuch@notmuchmail.org>
Precedence: list

On Wed, 18 Jan 2012 17:18:48 -0500, Aaron Ecay <aaronecay@gmail.com> wrote:
> On Wed, 18 Jan 2012 14:48:02 +0100, Pieter Praet <pieter@praet.org> wrote:
> > My original intent of conserving a key(chord) [1] (which in
> > retrospect was a fairly pointless exercise in and of itself
> > [2,3]) seems to have inconspicuously morphed into an equally
> > questionable crusade [4] against the `cl' package.
> >=20
> > As long there's other functions in Notmuch depending on
> > compile-time `cl', there's really no incentive whatsoever
> > to replace your perfectly fine solution.
>=20
> (This is not strictly related to the immediate issue of these patches,
> but now seems as good a time as any to discuss it.)
>=20
> Compile-time dependencies on =E2=80=98cl=E2=80=99 are absolutely not a pr=
oblem.
> Virtually every major elisp program depends on cl at compile time.
> Runtime dependencies are not allowed in code distributed with emacs
> because of RMS=E2=80=99s conservativism[1].
>=20
> Since notmuch isn=E2=80=99t distributed with emacs and has no aspirations=
 to
> ever be, the project could decide to require cl at runtime.  Many
> elisp programs do.  (A quick grep through my .emacs.d folder turns up
> anything.el and clojure-mode as two large/=E2=80=9Cmainstream=E2=80=9D pr=
ojects that
> do, as well as at least a dozen smaller utility files.)  So many emacs
> users have cl loaded all the time when they are using emacs.  But
> unless the project (i.e. us) decides explicitly =E2=80=9Cruntime cl is OK=
=E2=80=9D (or
> perhaps =E2=80=9Cit is not=E2=80=9D), contributors will always go back an=
d forth over
> using it.  To avoid patch and review churn, we ought to decide which
> of these we pick (and I vote for allowing runtime use.)
>=20

Consider me thoroughly convinced :)

No point in trying to conserve resources if they're already spent.

+1 for explicitly allowing runtime `cl'.


> Aaron
>=20
> Footnotes:
> [1] He specifically objects to the way that the cl package uses keyword
>     arguments, calling it un-Elisp-like.  He has resisted past efforts
>     to merge cl functions into Elisp core, although they are slowly
>     diffusing across the barrier.
>=20
> --=20
> Aaron Ecay


Peace

--=20
Pieter