[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