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

[Pieter Praet]

On Wed, 18 Jan 2012 17:18:48 -0500, Aaron Ecay <aaronecay at gmail.com> wrote:
> 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.)
> 

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