void variable with ctypes.el

[caludo]

Binary package hint: emacs-goodies-el

Hi.

I got this error when calling ctypes-read-file in emacs22:

(void-variable c-font-lock-keywords-2)

Update: a prerequisite is that you have a valid ~/.ctypes file, as you will if you have used ctypes at all before.

This causes startup of happycoders-emacs to fail.

The variable c-font-lock-keywords-2 is defined in cc-fonts.el. Hence, one has to (require 'cc-fonts) when emacs-major-version is >= 22 (and probably also for xemacs >= 21).

Regards,
Claudio

[xteejx (xteejx)]

Sorry no-one got back to you. You did not specify the version of emacs22 that you are using. Can you confirm if this is still a problem in jaunty please? Thank you.

[caludo (b-l-e-y)]

Yes, it is still a problem in Jaunty.

$ emacs --no-site-file --no-init-file

>>>>
(setq load-path (cons "/usr/share/emacs22/site-lisp/emacs-goodies-el" load-path))

(require 'emacs-goodies-el)

(ctypes-read-file nil nil t t)
<<<<

Error:

>>>>
Debugger entered--Lisp error: (void-variable c-font-lock-keywords-2)
  ctypes-font-lock-install-keywords(c-mode "[...]" ((1 c-font-lock-keywords-2) (1 c-font-lock-keywords-3) (2 c-font-lock-keywords-3 t)))
  ctypes-font-lock-add-keywords(c-mode ((1 c-font-lock-keywords-2) (1 c-font-lock-keywords-3) (2 c-font-lock-keywords-3 t)))
  apply(ctypes-font-lock-add-keywords c-mode ((1 c-font-lock-keywords-2) (1 c-font-lock-keywords-3) (2 c-font-lock-keywords-3 t)))
  ctypes-perform-action((c-mode c++-mode) t nil)
  ctypes-read-file(nil nil t t)
  eval((ctypes-read-file nil nil t t))
<<<<

I'm using Emacs 22.2-0ubuntu2.

[xteejx (xteejx)]

Thank you. Can you also give full step-by-step instructions on how to reproduce this, as typing the above alone does not cause any problems.

[caludo (b-l-e-y)]

Just start up Emacs as shown above, then activate the *scratch* buffer.

Copy'n'paste the elisp code and type M-x eval-buffer

If you want a backtrace, set the debug-on-error variable to t before evaluating the code.

[xteejx (xteejx)]

I am unable to reproduce this given the instructions above, sorry. Is there any chance you could provide a screencast of it, should make it easier to see the problem in action. Thank you.

[caludo (b-l-e-y)]

A screencast?! Are you kidding me? Maybe you can ask someone how to use Emacs?

Alternatively, just save the elisp code into a file. Then, run:

$ emacs --no-site-file --no-init-file --batch -l YOURFILE

[xteejx (xteejx)]

Correct, I have not used emacs before, but I am a bug triager. I do not believe sarcasm gets problems solved. Considering this bug is a year and a half old, and no-one has helped, maybe it would be better if you logged onto IRC at irc.freenode.net at the #ubuntu-bugs channel and see if there is anyone there who is more apt at using/debugging emacs.

[caludo (b-l-e-y)]

I wasn't trying to be sarcastic.

Anyway, what's the point? I already gave the solution in the report itself.

[xteejx (xteejx)]

Ok, no worries caludo, I will have a look and see if anyone can help with this. Your patience is very much appreciated. Thank you.

[Jonathan Marsden (jmarsden)]

Unlike Teej, I have used emacs before ... pretty much daily for the last 15 years or so :)

Like Teej, I also am unable to reproduce this issue in Ubuntu Jaunty 9.04 (amd64) with the supplied instructions.

My attempt at replication from a bash shell prompt, using the information provided by the submitter, is:

  # Make sure emacs and emacs-goodies-el are installed
  sudo apt-get install emacs22 emacs-goodies-el
  # Run emacs and evaluate the elisp which should trigger the reported issue
  emacs -- no-site-file --no-init-file --batch -l <(echo -e "(set-variable 'debug-on-error t)\n(setq load-path (cons \"/usr/share/emacs22/site-lisp/emacs-goodies-el\" load-path))\n(require 'emacs-goodies-el)\n(ctypes-read-file nil nil t t)\n)")

This does not generate an error or backtrace at all on my system.

In case it helps:

jonathan@black:~$ lsb_release -ircd
Distributor ID: Ubuntu
Description: Ubuntu 9.04
Release: 9.04
Codename: jaunty
jonathan@black:~$ uname -a
Linux black 2.6.28-13-generic #44-Ubuntu SMP Tue Jun 2 07:55:09 UTC 2009 x86_64 GNU/Linux
jonathan@black:~$ dpkg -l emacs22 emacs-goodies-el | grep emacs
ii emacs-goodies-el 29.4-1ubuntu2 Miscellaneous add-ons for Emacs
ii emacs22 22.2-0ubuntu2 The GNU Emacs editor (Emacs 22)
jonathan@black:~$

It is likely that this bug really does exist, but the supplied information appears to be insufficient to reproduce it.

In particular, the variable c-font-lock-keywords-2 is used within ctypes.el and is defined in cc-fonts.el. But the supplied elisp is just not triggering the problem, at least for me.

caludo: Any ideas on a more reliable way to trigger this bug? Or could try to a fresh install of Ubuntu Jaunty 9.04 and reproduce it there (maybe in a virtual machine, if you don't have a spare PC for this sort of thing)?

Thanks! BTW, once I can reproduce it, I can probably create a debdiff and get a fix uploaded fairly quickly...

[caludo (b-l-e-y)]

Yes, you're right. There is a bit more required to trigger this error.

Actually, a ~/.ctypes file is required which is read when calling the ctypes-read-file function.

Here is a minimal one which triggers the error:

>>>>
;; This file has been automatically generated by the Emacs package `ctypes'.
;; Please use the `ctypes-read-file' to load it.

(ctypes-set-types 'c-mode '("foo"))

(ctypes-set-types 'c++-mode 'nil)
<<<<

Btw, I've tested it using a fresh jaunty installation.

[era (era)]

With these instructions, the bug can be reproduced. Contrary to the commentary in ctypes.el, it does not help if you add (require 'ctypes) to your Emacs init file, either.

The function ctypes-read-file is exposed as an autoload, and should probably somehow (require 'cc-mode) directly or indirectly.

The simple straightforward fix for this specific bug is to add that to the ctypes-read-file function and be done with it. But should the other autoload functions have that, too? Or should perhaps ctypes.el simply (require 'cc-mode) as a prerequisite for the whole module? (I imagine it was a conscious design decision to not do that, but perhaps then that issue should be revisited.)

If the original upstream author is responsive, perhaps these questions should be brought up with him. (But PSG's comments further down in the file indicate he is not reachable.)

For the record, here are repro steps showing how a new user could realistically trigger this bug on a virgin install of Emacs and emacs-goodies-el.

* M-x customize-group <ret> ctypes <ret>

  Ctypes Install: toggle on and save for future sessions

  Ctypes Write Types At Exit: enable and save for future sessions

* Visit a new file C-x C-f /tmp/ctypes.c and enter the following contents:

  typedef foo bar;

* M-x ctypes-buffer <ret> <ret>

* Quit Emacs; verify that ~/.ctypes was created when quitting Emacs

* Start a new Emacs instance

* M-: (setq debug-on-error t) ; maybe

* M-x ctypes-read-file <ret> ~/.ctypes <ret>

=> (void-varliabe c-font-lock-keywords-2)

[Peter S Galbraith (psg)]

Thanks! Should be fixed in version 32.0.

[Peter S Galbraith (psg)]

Opps. Meant fixed upstream. I don't really understand the system here so will leave it alone.

[era (era)]

I'll mark it as "Fix Committed" for now.

[Peter S Galbraith (psg)]

Thanks!