[PATCH] v2 [RFC] emacs: merge overhauled `notmuch-cycle-notmuch-buffers' into `notmuch'

[Aaron Ecay]

On Wed, 18 Jan 2012 14:48:02 +0100, Pieter Praet <pieter at 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.
> 
> 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.

(This is not strictly related to the immediate issue of these patches,
but now seems as good a time as any to discuss it.)

Compile-time dependencies on ‘cl’ are absolutely not a problem.
Virtually every major elisp program depends on cl at compile time.
Runtime dependencies are not allowed in code distributed with emacs
because of RMS’s conservativism[1].

Since notmuch isn’t 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/“mainstream” projects 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 “runtime cl is OK” (or
perhaps “it is not”), contributors will always go back and 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.)

Aaron

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.

-- 
Aaron Ecay