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

[Stephen J. Turnbull]

Wulf C. Krueger writes:

 > It always happens. I just found out it doesn't even happen with replies
 > only but even for new messages. The following backtrace is being
 > generated (this time *without* the inf. loop and without aborting):
 > 
 > (40) (general/warning) Error in unknown: Invalid function: (macro . #<compiled-function (&rest cdr) "...(6)" [cdr function lambda] 3 737017>)

This is most likely not an XEmacs problem.  What's happening here is
that compiled code is trying to call a macro.  Since a macro can
always be expanded correctly at compile-time, and is much more
efficient that way, there is no support in XEmacs LISP for calling
macros from compiled code; instead the expansion *must* be inlined.
(AFAIK this is true of Emacs as well.)  This requires that all macros
called by the library be defined in the LISP environment at compile
time.

A grep of the XEmacs package tree says that the only macro with
arguments '(&rest cdr)' is lambda-default in eieio.el.  (Of course you
may have a library that isn't available to me with that signature.)
So if you ensure that eieio is loaded at package build time (probably
Gnus), this problem will probably be fixed.

Another possibility is that you have the on-the-fly byte-compiler
enabled for Gnus.  This is a bad idea in XEmacs, because Gnus is far
more heavily tested with Emacs, and the two versions have somewhat
different ideas of what should be a macro and what should be loaded
when.  So this kind of thing can happen (but I admit that if this is
causing the bug you see, it's the first time I've seen it in the real
world).

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

 >  >> Oh, btw, why is my XEmacs standard menu ("File", etc.) suddenly in
 >  >> German?
 >  >> LC_CTYPE=de_DE.utf8 LC_MESSAGES=en_US.utf8

 >  SJT> Probably XEmacs just looks at the LC_CTYPE [...]
 >  SJT> I would guess this should follow LC_MESSAGES rather than LC_CTYPE,

 > That would indeed be the correct way to determine the language
 > environment if LANG is not set or usable, I think.

Actually, if the relevant LC_ variable is set, POSIX says it overrides
LANG.

 > Anyway, I'll proceed with removing the package for now but I'd really be
 > grateful if this could be corrected.

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

Thanks for responding!