[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#21464: 25.0.50; [cc-langs] void-function cadar
From: |
Stefan Monnier |
Subject: |
bug#21464: 25.0.50; [cc-langs] void-function cadar |
Date: |
Mon, 14 Sep 2015 21:33:19 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) |
>> Using cl-lib instead of cl would solve such issues easily since we could
>> use cl-cadar and (require 'cl-lib) at run-time instead of only requiring
>> cl at compile-time.
> CC Mode in Emacs (as opposed to XEmacs) has been using cl-lib instead of
> cl for some weeks, now.
By "using cl-lib" I mean "assume cl-lib is always available" and
"don't use cl anymore anywhere".
That's a lot more convenient than the current testing and using various
macro wrappers depending on the circumstance and it'd let you use
any CL functions and macros anywhere any time.
> It would be bound to clash with a cl-lib in Emacs
Your assumptions are faulty, I think.
You'd put it in a subdirectory, say "cc-cl-lib" (so it's not in
load-path by default) and in cc-compat.el you'd do something like:
(unless (featurep 'cl-lib)
(unless (locate-library "cl-lib")
(add-to-list 'load-path
(expand-file-name "cc-cl-lib"
(file-name-directory load-file-name))))
(require 'cl-lib))
or
(unless (featurep 'cl-lib)
(require 'cl-lib
(unless (locate-library "cl-lib")
(expand-file-name "cc-cl-lib/cl-lib"
(file-name-directory load-file-name)))))
> (or a cl in XEmacs) somehow.
The cl-lib.el I'm talking about is the one in GNU ELPA, which is
basically loads cl.el and then adds a whle bunch of aliases under the
new "cl-*" namespace. So no, it doesn't clash with cl.el, instead it
relies on it.
> I'm marking this bug as closed.
Indeed, thanks,
Stefan