On Wed, 18 Jan 2012 14:48:02 +0100, Pieter Praet <pie...@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 _______________________________________________ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch