[Bug: 21.5-b27] font-lock-fontify-* / infinite loop

Wulf C. Krueger wk at mailstation.de
Tue Jan 9 14:27:30 EST 2007


Hallo Stephen!

"SJT" == Stephen J Turnbull <stephen at xemacs.org> writes:

 >> (40) (general/warning) Error in unknown: Invalid function: (macro
 >> . #<compiled-function (&rest cdr) "...(6)" [cdr function lambda] 3
 >> 737017>)
[Macros called from compiled code]
 SJT> A grep of the XEmacs package tree says that the only macro with
 SJT> arguments '(&rest cdr)' is lambda-default in eieio.el.  

A grep here shows the following which looks to me like a XEmacs file:

/usr/lib/xemacs-21.5-b27/lisp/subr.el:(defmacro lambda (&rest cdr)

 SJT> (Of course you may have a library that isn't available to me with
 SJT> that signature.)  So if you ensure that eieio is loaded at package
 SJT> build time (probably Gnus), this problem will probably be fixed.

I "require"d eieio while re-building Gnus this time - didn't help. (I
wouldn't know why it would anyway because I don't even know what it does
and I can't remember ever using it nor is there any reference to it
anywhere in my setup.)

I've checked that none of my own compiled stuff calls anything with the
"rest cdr" argument and to make sure, I've even deleted all of my own
compiled files - didn't help either.

 SJT> Another possibility is that you have the on-the-fly byte-compiler
 SJT> enabled for Gnus.  

I strongly doubt that as I wouldn't even know how to enable it. :-)

 SJT> Again, the solution is probably to load eieio.  This might also
 SJT> explain why turning font-lock on and off solves the problem;
 SJT> somehow the needed macro gets loaded.

I have tried loading eieio both from my configs and immediately before
triggering the bug using load-library - didn't help.

Any other ideas? I mean, why would Gnus or something related try to use
eieio in the first place? This behaviour is immensely irritating and I
really need to get rid of the problem - preferably without sacrificing
font locking. :)

 SJT> Given the quality of the translation you describe, we should just
 SJT> remove it until somebody is willing to maintain it properly.

Yes, that would be reasonable, too. :-)

-- 
Grüße, Wulf



More information about the XEmacs-Beta mailing list