dv> Obviously, XEmacs took my package source directory for what it dv> is not. After renaming it to XEmacs-Packages (note the dv> uppercase) and reinstalling in order to update the symlinks, dv> everything went fine again. ms> Ben yelled at me sufficiently to implement this. It's an ms> intentional feature, and it only happens with an in-place ms> XEmacs. This, er, doesn't seem to be documented anywhere. info xemacs 'startup paths' says "If you run in-place, these [hierarchies] are direct subdirectories of the build directory." What is it that Ben wanted? Is this just so that Windows users can put their installed package hierarchy in c:\xemacs-packages and their sources in c:\xemacs or something like that? dv> To me, running in place would mean the ability to find the dv> packages in my compiled cvs source tree withtout having to dv> install them (whether by symlinks or not). But that's not that dv> hey ? ms> Yes, that's what it is. As opposed to a regular package ms> hierarchy available to an in-place core. Hm? I don't understand. It seems that you are saying that I should be able to use a package source tree which is a neighbor of the build directory as a package hierarchy. That's clearly not true; otherwise there would be no need to rename your package source hierarchy. It would just work. I can think of several reasons why this is a bad idea, anyway. (1) As implemented, it causes XEmacs to fail in a very non-transparent way. This can be fixed as far as I'm concerned by testing `(featurep 'xemacs-base)' or the equivalent, and reporting (format "xemacs-base packages not found. Perhaps your\n" "package hierarchies are weird? %s" package-hierarchy-roots) or something like that (`emacs-roots' probably doesn't give enough information). But given (2), maybe it's preferable to revert this. (2) In general, when working on packages you[1] should probably be testing with an installed XEmacs; when working on the core, you should probably be testing against installed packages. If you know what you're doing, and want to test development packages against a development xemacs, it's easy enough to change this with an environment variable, or by putting development packages in your private hierarchy. Footnotes: [1] Me, anyway. :-) -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."