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

Austin Clements amdragon at MIT.EDU
Wed Jan 18 16:48:10 PST 2012


Quoth Aaron Ecay on Jan 18 at  5:18 pm:
> 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.)

I agree with Aaron.  There's no excuse for some of the functionality
that can only be found in cl to be missing from core Emacs and it's
ridiculous to re-implement it time and again (I count at least five
obvious reimplementations of remove-if in code shipped with Emacs).
There are a lot of compelling reasons to use cl and I'm not aware of
any good technical reasons why notmuch shouldn't.


More information about the notmuch mailing list