could one of the package experts (Michael?) look into this, please.
Gunnar
andrei(a)johnlang.com writes:
Full_Name: Andrei
OS: RedHat Linux 7.0
Version: 21.1.14
mule: yes
severity: Aggravating
Submission from: (NULL) (63.97.198.76)
This is an update to bug #1621, broken font-lock in XEmacs.
It turns out that the problem is triggered by the installation of a certain
package, specifically ESS (see
http://franz.stat.wisc.edu/pub/ESS/README.html).
However, the reason for the problem is that XEmacs is doing a Wrong Thing.
Here is the text of email I send to a guy who was helping me debug it:
<----------
I had a flash of brilliance and remembered the existence of a wonderful tool
called 'strace'. Running XEmacs under it and grepping through the output quicky
showed what was going on.
Basically, XEmacs recurses through the directories under
/usr/lib/xemacs/site-packages reading their contents and looking for certain
files. In all directories, nested however deep, it tries to find certain files
(that is, certain filenames). The filenames that it looks for are:
auto-autoloads{.el|.elc}
leim-list.el
cl-seq.elc
mailcrypt{.el|.elc}
font-lock{.el|.elc}
I understand auto-autoloads, but the fact that it looks everywhere for the other
files smells like an ugly kludge. Seems like one of the maintainers was too lazy
to specify a proper place for these files, so he just hacked XEmacs to look
everywhere for them. Don't you just love it when people decide to simplify their
lives in this way?
And now, to my problem. ess-5.1.18/lisp contains a directory called 19.29,
purely for being able to deal with obsolete versions of {X}Emacs. And, guess
what, it contains a file called font-lock.el. Well, XEmacs, in its wisdom, grabs
it and executes it. Of course, it screws up XEmacs horribly, not enough to crash
it, but enough to break font-lock.
My solution was simple: I just deleted the 19.29 directory. The general solution
(besides applying a cluestick to the head of the above-mentioned maintainer)
would probably be to rename the font-lock.el file to something else and hope
that XEmacs does not kludge in any more just-find-it-anywhere filenames. Note
that renaming the 19.29 directory would not help since XEmacs recurses all
directories and doesn't seem to care about their names.
Thanks a lot for your help, I hope I am done with this particular bug.
Andrei
------->