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

Wulf C. Krueger writes: 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. Actually, if the relevant LC_ variable is set, POSIX says it overrides LANG. Given the quality of the translation you describe, we should just remove it until somebody is willing to maintain it properly. Thanks for responding! _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta