GNU bug report logs - #21464
25.0.50; [cc-langs] void-function cadar

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 21464 in the body.
You can then email your comments to 21464 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mark Oteiza <mvoteiza <at> udel.edu>
To: bug-gnu-emacs <at> gnu.org
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

Message #8 received at 21464 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Mark Oteiza <mvoteiza <at> udel.edu>
Cc: 21464 <at> debbugs.gnu.org
Subject: Re: bug#21464: 25.0.50; [cc-langs] void-function cadar
Date: Fri, 11 Sep 2015 21:16:47 -0400

> "Eval error in the ‘c-lang-defvar’ or ‘c-lang-setver’ for ‘comment-start’ (source eval): (void-function cadar)"

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.

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.

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.


        Stefan

Message #13 received at 21464-done <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: 21464-done <at> debbugs.gnu.org
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#21464: 25.0.50; [cc-langs] void-function cadar
Date: 14 Sep 2015 13:47:01 -0000

Hello, Stefan.

In article <mailman.969.1442020629.19560.bug-gnu-emacs <at> gnu.org> 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).

Message #16 received at 21464-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 21464-done <at> debbugs.gnu.org
Subject: Re: bug#21464: 25.0.50; [cc-langs] void-function cadar
Date: Mon, 14 Sep 2015 21:33:19 -0400

>> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.