unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#21464: 25.0.50; [cc-langs] void-function cadar
@ 2015-09-11 21:16 Mark Oteiza
  2015-09-12  1:16 ` Stefan Monnier
       [not found] ` <mailman.969.1442020629.19560.bug-gnu-emacs@gnu.org>
  0 siblings, 2 replies; 4+ messages in thread
From: Mark Oteiza @ 2015-09-11 21:16 UTC (permalink / raw)
  To: 21464


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





^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#21464: 25.0.50; [cc-langs] void-function cadar
  2015-09-11 21:16 bug#21464: 25.0.50; [cc-langs] void-function cadar Mark Oteiza
@ 2015-09-12  1:16 ` Stefan Monnier
       [not found] ` <mailman.969.1442020629.19560.bug-gnu-emacs@gnu.org>
  1 sibling, 0 replies; 4+ messages in thread
From: Stefan Monnier @ 2015-09-12  1:16 UTC (permalink / raw)
  To: Mark Oteiza; +Cc: 21464

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





^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#21464: 25.0.50; [cc-langs] void-function cadar
       [not found] ` <mailman.969.1442020629.19560.bug-gnu-emacs@gnu.org>
@ 2015-09-14 13:47   ` Alan Mackenzie
  2015-09-15  1:33     ` Stefan Monnier
  0 siblings, 1 reply; 4+ messages in thread
From: Alan Mackenzie @ 2015-09-14 13:47 UTC (permalink / raw)
  To: 21464-done

Hello, Stefan.

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






^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#21464: 25.0.50; [cc-langs] void-function cadar
  2015-09-14 13:47   ` Alan Mackenzie
@ 2015-09-15  1:33     ` Stefan Monnier
  0 siblings, 0 replies; 4+ messages in thread
From: Stefan Monnier @ 2015-09-15  1:33 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: 21464-done

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





^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2015-09-15  1:33 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-09-11 21:16 bug#21464: 25.0.50; [cc-langs] void-function cadar Mark Oteiza
2015-09-12  1:16 ` Stefan Monnier
     [not found] ` <mailman.969.1442020629.19560.bug-gnu-emacs@gnu.org>
2015-09-14 13:47   ` Alan Mackenzie
2015-09-15  1:33     ` Stefan Monnier

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).