Re: Loading .el files - various errors

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. What errors? 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