>>>> "Ed" == Ed Allen Smith
for info don't seem to work, BTW. It's also not helpful to be
asked to do a "M-x emacs-version" when the results from that show
up in the minibuffer, which results in it not being
cuttable-and-pasteable (which might be necessary if this
bug-mailing function doesn't work).
If things are that hosed, there are other reasons why you're going to
need to be sophisticated enough to use M-x view-lossage or C-x b "
*Message-Log*" to get the output. I think our play here is to make
the report function as robust as possible.
B. Errors in a custom.el file show up as being in the init.el file
(specifically, if there's a parentheses imbalance in the
custom.el file, an "End of file" error shows up for the init.el
file... not the custom.el file).
Because of the way XEmacs handles these files, I suspect that you
probably have imbalanced parens in _both_ files. I'll check when I
get back to my devel workspace, though.
N.B. custom.el is designed to be written only by code that prints
sexps, there is no user-editable code in there. If you are getting
imbalanced parens in custom.el, all I can say is "whatever you're
doing, it's unsupported by XEmacs.org".
C. XEmacs gives errors when there isn't an init.el file, which is
particularly maddening when the cause of removal of the init.el
file is the previous problem.
D. auto-autoload.el should _not_ be doing "error" if a file is
It's not doing error (which means to stop loading autoloads and throw
to top-level), it's giving a warning about a very-hard-to-debug
situation. Live with it or use display-warning-minimum-level; that
information is needed to help other users.
already included; it should simply return.
Wrong. If auto-autoloads detects that it has been previously loaded,
that means one of three things: a bad build, multiple copies of
packages on your load-path, or a seriously mutilated load-path.
Either way, we want XEmacs to yell about it.
Ed> (As it is, I'm writing a Perl script to correct all the
Ed> auto-autoload.el files, since there doesn't seem to be a way
Ed> to automatically reconstruct them properly.
Don't do this. It is a known design bug in the package system that
there is no easy way to build the packages correctly without checking
out the whole source hierarchy. However, it is not going to be easy
to fix in a backward compatible way. In the meantime I strongly urge
you to find all the copies of the package hierarchy you have
installed, delete them, download the sumo tarball (tarballs if you
want Mule), and reinstall packages from scratch. Unless you have a
really slow (worse than ISDN) link, this will be faster than doing it
by hand, and much more likely to be correct.
Since you only show the md5 shadow, I conclude there is something
wrong with either your build or your init files (user or system);
otherwise you would not be getting duplicate loads of the packages.
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py