Wulf C. Krueger writes:
I "require"d eieio while re-building Gnus this time -
A grep here shows the following which looks to me like a XEmacs
/usr/lib/xemacs-21.5-b27/lisp/subr.el:(defmacro lambda (&rest cdr)
OK, I guess that's just what a compiled macro looks like: a lambda
form, except with the car 'macro instead of 'lambda. That makes
sense. (I'm not a byte-compiler hacker, I just know the symptom and
the high-level solution.) I ignored the core LISP because all those
macros are dumped, so they will be properly compiled.
SJT> Another possibility is that you have the on-the-fly
SJT> enabled for Gnus.
I strongly doubt that as I wouldn't even know how to enable it. :-)
You don't have to; it's a Gnus "feature" (Microsoft Windows-style),
and you have to disable it (at least, that used to be the case).
Gnus is very helpful in crashing XEmacs. That's the main reason why I
run it---as a torture test.
Any other ideas? I mean, why would Gnus or something related try to
eieio in the first place?
*shrug* All I can say is that I am no longer willing to waste surprise
on anything that Gnus does. I was simply applying the trivial pattern
match on the argument list, and eieio is a generic object library
(similar in purpose to CLOS or C++ STL), so Gnus using it is not
This behaviour is immensely irritating and I really need to get rid
of the problem - preferably without sacrificing font locking. :)
Well, you could use the XEmacs package of Gnus which is known to work;
that's why it's in the packages.
If you must have Gnus from Gnus CVS (I'm assuming that you meant Gnus
CVS, otherwise you should just use the binary package), you're going
to need to find the dependency and ensure that the macro definition is
loaded before the file that references it is compiled.
That is a Gnus question, best posed on ding, I think. There is no
XEmacs bug visible at this point, everything is working as designed.
XEmacs-Beta mailing list