--- Begin Message ---
Subject: |
25.0.50; [cc-langs] void-function cadar |
Date: |
Fri, 11 Sep 2015 17:16:20 -0400 |
Hi,
>From emacs -Q, loading
(eval-when-compile (require 'cc-langs))
(c-initialize-cc-mode t)
(c-init-language-vars c-mode)
gives
"Eval error in the ‘c-lang-defvar’ or ‘c-lang-setver’ for ‘comment-start’
(source eval): (void-function cadar)"
So, similar code for some derived mode errors
In GNU Emacs 25.0.50.1 (x86_64-unknown-linux-gnu, X toolkit, cairo version
1.14.2, Xaw scroll bars)
of 2015-09-11
Repository revision: a0ec54ae073abd671bd43002eff0267f5fe8b306
--- End Message ---
--- Begin Message ---
Subject: |
Re: bug#21464: 25.0.50; [cc-langs] void-function cadar |
Date: |
14 Sep 2015 13:47:01 -0000 |
User-agent: |
tin/2.3.1-20141224 ("Tallant") (UNIX) (FreeBSD/10.1-RELEASE-p16 (amd64)) |
Hello, Stefan.
In article <address@hidden> you wrote:
>> "Eval error in the ?c-lang-defvar? or ?c-lang-setver? for ?comment-start?
>> (source eval): (void-function cadar)"
I've gone and replaced cadar with cadr/car in the two places it appeared
in cc-langs.el. They were the only occurrences of c[ad]\{3,\}r in CC
Mode. There are quite a few compositions of caar, etc., with car and cdr,
and even compositions of car and cdr, presumably dating from a time before
caar etc. existed.
> 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.
> I know we've discussed it already, but I urge you (Alan) to take
> another look at the idea of unconditionally using cl-lib (and just
> bundling it with cc-mode). I'd be happy to help you do that.
Bundling cl-lib with CC Mode doesn't feel like the Right Thing to do. It
would be bound to clash with a cl-lib in Emacs (or a cl in XEmacs)
somehow.
> Then you'll be free to use CL functions (via the cl-*
> namespace) anywhere without having to worry about whether it's used at
> runtime or compile time.
> This is bound to happen sooner or later since cl.el is slated to move from
> lisp/emacs-lisp to lisp/obsolete and then to GNU ELPA.
> But even if cl.el were to stay in lisp/emacs-lisp, I think CC-mode
> maintenance would benefit from it.
Possibly. But there doesn't seem to be an urgent need for it at the
moment.
I'm marking this bug as closed.
> Stefan
--
Alan Mackenzie (Nuremberg, Germany).
--- End Message ---