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. > > > > 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.) > Consider me thoroughly convinced :) No point in trying to conserve resources if they're already spent. +1 for explicitly allowing runtime `cl'. > 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 Peace -- Pieter