Re: Loading .el files - various errors

Ed> I apologize if this is overly bad-tempered, Not bad-tempered IMO. But not knowing your particular situation, I addressed what I believe to be the most common reasoning for the particular issues you raise. Some of them are XEmacs bugs, but mostly they are constraints we have to live with. Ed> If I wanted to deal with software without user-editable parts, Ed> I wouldn't use open-source software... XEmacs has _lots_ of user-editable parts. custom.el happens to be one of the few that you should not edit. Really. If custom.el is broken, it is possible to lose all your customizations. Ed> I'm afraid that you'll need to get the customization features Ed> a _lot_ better (including clearer, etcetera) before it won't Ed> be necessary to edit custom.el, *shrug* You've been warned. You really really should move it somewhere else, take what you need, and put that in site-init. Then _delete_ custom.el and reset what is left by hand. There is work being done on creating "custom themes", but I don't know when it will be usable, or whether those themes will be easily portable across users. They're supposed to be.... Ed> Then why is the function called "error" (holding head...)? I didn't see any "errors" in your list, just warnings. AFAICT those warnings were generated by `display-warning'. ... OK, you're right, auto-autoloads is calling error. Evidently for packages those errors (maybe a better term would be "exceptions", the primitive function that implements this stuff is called "signal") are caught and turned into warnings, I'm not sure where. If this happens with the "core" lisp it is _not_ caught and XEmacs does return to top-level (we have a bug like that going on currently in the devel branch, where we're working on autoloads for DSOs). Ed> You're saying that we'll never need any of the information Ed> that display-warning-minimum-level will cut off? No, you are. :-) I know we need that information; it's up to you to decide if you want it turned off because you don't like it. If you _do_ want that information later, it will be _logged_ to the buffer named " *Message-Log*"; you just don't get the pop-up warning. There's also `display-warning-suppressed-classes' which might be more appropriate, except that it looks like the class is "warning" which you probably don't want to suppress as a class. Ed> Not the case, unless it's looking in the old xemacs-20.4 Ed> directory. It might very well be doing so if it was configured that way. However, I don't think so, because it's complaining about ecrypto, which is not a 20.4 package, it's only a couple months old. Ed> It's loading from one directory and its subdirectories, the Ed> major ones being lisp (normal installed code), xemacs-packages Ed> (packages), and site-packages (one subdirectory, lisp, with Ed> site-init.el in it). Try evaluating (cl-prettyprint load-path) in the buffer named "*scratch*". Use C-x h M-x sort-lines RET to sort the lines so that identical ones will be neighbors and see what you get. Also the output of xemacs -batch -debug-paths would be useful. Ed> This has not caused any easily-noticeable problems; it's Ed> possible that things are being slowed by loading more than Ed> once, however, especially when going into the customization Ed> code. You _will_ run into problems with this eventually when you have two non-identical versions of some library and ignore the warnings. Ed> What? Only possibility is because configure needs to allow Ed> input of more detailed path information, _What_ "detailed path information"?!!?! If you're mucking with the definitions of $lispdir and/or $sitelispdir in the Makefile then you may have introduced multiple mentions of the packages in there. We are not kidding when we call these options "DEPRECATED". Furthermore, that will not show up in Installation, which is generated by configure. Ed> unless configure already can do this, and it isn't documented? If you mean stuff like --bindir=/path/to/home/of/user/binaries/ and --infodir=/path/to/info/, yes, configure can do that. Here's the list: dnl Has the user specified one of the path options? prefix | exec_prefix | bindir | datadir | statedir | libdir | \ mandir | infodir | infopath | lispdir | etcdir | pkgdir | \ archlibdir | docdir | package_path | moduledir ) Here's the documentation, such as it is: $ ./configure --usage | fgrep -A9 'Installation options:' Installation options: --prefix=DIR Install files below DIR. Defaults to `/usr/local'. --with-prefix=no (Bool) Compile the value of `--prefix' into XEmacs. --infodir=DIR Install XEmacs Info manuals and dir in DIR. --moduledir=DIR Install dynamic modules in DIR. You may also specify any of the `path' variables found in Makefile.in.in, including `--bindir', `--libdir', `--docdir', `--lispdir', `--sitelispdir', `--datadir', `--mandir' and so on. These options are DEPRECATED; see INSTALL. (I don't have a copy of the old configure.usage around, this is the 21.4.10 version. There is similar wording somewhere in ./configure --help for 21.4.9, though.) Ed> (sh configure --help gives, interestingly enough, the error Ed> "|: No such file or directory", which I will confess I find Ed> odd; I can't replicate this on Linux. I'll try some other systems, but this looks like something that would be specific to Irix, then. Ed> (unless it's a problem with installing the updated versions - Ed> .emacs does _not_ seem to get created properly, for instance, Ed> if there was an old version that is now supposed to be Ed> referring to .xemacs/init.el). Details? Works for me, as they say. So I can't guess how it's not working for you. Ed> Umm... methinks you are making assumptions of perfect Ed> coordination of packages dependent on each other wanting Ed> loading (possibly when they autoload to supply a function, if Ed> that's how this works?) that may not be allowing for Ed> unanticipated but non-erroneous situations. Methinks you're not allowing for the fact that something this ugly would have been reported multiple times, and I've never heard of it before. It is possibly an XEmacs bug, this stuff is incredibly hairy (it used to be worse, and often simply incorrect), but whatever it is it requires a rather unusual environment to manifest. Here's the scheme: normally the code in libraries is declarations and definitions of data and functions. This means that up to certain ugliness concerned with inlining of Lisp macros during compilation, order of loading doesn't matter, as long as functions are not being redefined. Where files recursively require each other, you can simply provide feature-a before requiring feature-b. Since autoloading simply executes all the necessary loading before returning to execute the user code, all the relevant functions should be properly defined in the environment when the user code starts executing again. This _does_ work as desired unless someone deliberately introduces code that manipulates the load process directly. Now, what the auto-autoloads do is to set up the triggers for lazy loading when a function is called. This allows XEmacs to dispense with requires in init.el. The only exceptions are programs like filladapt, whose entry points are modified core functions, and therefore may only be loaded explicitly on user request. If you "double-load" an autoload during the initialization process, you are OK (unless some package is set up to do perverse things while loading). That's why those double-loads are caught and converted from errors to warnings at initialization. However, consider the example of filladapt. Suppose you load filladapt, and then one of its functions gets overwritten by an autoload? filladapt cannot find out about this---it does not reset the filladapt feature to nil. Thus, a duplicate load of an auto-autoloads file is likely to be a severe error. Ed> I didn't do the editing by hand... Of course not. But you won't do any debugging by script.... Ed> This has not caused any easily-noticeable problems; it's Ed> possible that things are being slowed by loading more than Ed> once, however, especially when going into the customization Ed> code. It probably won't cause any problems if in fact what is happening is that identical packages are being loaded twice at initialization. If the packages are not identical, you could have dependency problems where an old version of the code is the one left when all is said and done, or there are mixtures of old and new code, and if happens after some of the packages are actually loaded, you could have bugs like the filladapt case above. Ed> If you're meaning the package-dependency coding, I would agree Ed> that there are problems - many packages seem to be down as Ed> depending on gnus when they actually simply are _helpful_ to Ed> be used _with_ gnus, Those are compile-time dependencies. If they require or load a file from Gnus, or autoload a function from Gnus, or do so recursively via some other file they load .... This is a reasonable heuristic for run-time dependencies, too, with the exception of dependencies on Gnus. Lisp has a lot more mutual recursion than I ever saw in Perl. Ed> (BTW, speaking of this, if one is not doing a MULE xemacs, why Ed> pray tell is it considered necessary to have iso-8859-1 Ed> capabilities, as opposed to us-ascii? I note that Ed> 'x-iso8859-1.el' and 'iso8859-1.el' are, for some reason, not Ed> in the 'mule' directory - why that one is present at all in a Ed> non-MULE xemacs is also mystifying.) This is The Kitchen Sink. You can do 8-bit character sets, including all the ISO-8859 sets, KOI8 and VISCII in a non-Mule XEmacs, so we provide some helper functions for folks (including English speakers who need some of the graphics, the pound sterling sign, and the Euro) so that the use is a little more convenient. The mule-packages hierarchy is not the home for Mule functionality. It is a quarantine area for code that a non-Mule XEmacs can't read correctly. Whenever possible we move code out of there, and into the xemacs-packages hierarchy. Ed> incidentally, if people ever start looking at doing Xemacs Ed> with threading, Not soon. Minimum of a year from now. -- 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