Re: [Bug: 21.4.18] site-lisp not in load-path

vin> FWIW, I think it's unlikely that the (stable) 21.4 branch vin> will ever support the new feature 'site-packages/*/lisp', but vin> sometimes patches convince me to change my mind. Mike has claimed that this is basically already supported in XEmacs, at least in 21.5 but ISTR in 21.4 too; what's missing is an audit of the build infrastructure, and maybe a few tweaks to the package- finding code. In fact, the following proposal can probably be implemented as a normal XEmacs package with a bit of abuse of its auto-autoloads file. For packages built entirely by third parties, the following transition strategy is easy to implement and essentially riskless but was vetoed at the brainstorm stage by Mike (and I think Ben) several years ago (and ignored by everybody else). (1) Create a new hierarchy "opaque-packages" sibling to xemacs-packages, mule-packages, and site-packages. (2) Add code to the package-autoloading code to look in each subdirectory of opaque-packages for the library "lisp/auto-autoloads". These packages are called "opaque" because auto-autoloads is entirely responsible for configuring the package, including setting up load-path, exec-path, and any other LISP environment the package needs. XEmacs knows nothing about the internal structure of such packages; it doesn't even know for sure that .../ess/lisp contains any LISP other than auto-autoloads. It's not called "3rd-party" because I think XEmacs packages should work this way too! Of course we _should_ provide further infrastructure support down the road, including 1. other automatic package configuration like custom-load and _pkg.el 2. a utility to insert the package's main LISP directory in load-path (the arg is a path relative to the package's root, default "lisp") 3. similar utilities for data, info, executables and probably other stuff. But we don't need to do it immediately. In fact, we shouldn't do anything for opaque-packages automatically, not before thinking about issues of standalone executables (think oo-browser) and ELLs, both of which should be installable as packages (although because they're platform-dependent, I don't think XEmacs.org should distribute them, except perhaps for MS Windows). Since as it stands we're asking such packages to do random things to the LISP environment, a warning should be logged (always) and displayed (by default) when an opaque package is auto-loaded. There should be a customizable list of expected opaque packages (ie, their main feature-symbols) and warning display would be suppressed for those packages. Note that complex packages like JDEE and Emacspeak already have internal mechanisms for finding their data, executables, and help; they would basically just drop in to this scheme with a couple of autoload cookies that they probably already have. NB: At this point, this has nothing to do with XEmacs builds of such packages and nothing to do with pui. It would make David Kastrup's proposal to distribute AUCTeX from the AUCTeX project a bit simpler, but it doesn't address his complaints about the XEmacs distribution of AUCTeX at all. Of course in the near term I'd like to support a lot of the "usual setup" automatically, and also support such packages in pui (pretty trivial, I would think, since pui just untars to install, and does "cat pkginfo/$package.MANIFEST | xargs rm" to uninstall). Supporting builds of such packages would be a longer term project, but presumably not terribly hard for 3rd party packages since upstream would have already done most of the work. I think it's a good bet that Steve Youngs would like this too (he's the guy who implemented the symlink trees for run-in-place for the packages, which is needed primarily because the package and functional layers in source packages are reversed in installed packages). We'd also probably want to install info and maybe certain kinds of data (toolbar icons, for example) to a few shared directories rather than to dozens of $package/info directories, I guess. But that's an optimization; it can wait, I think. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.