jpw> The `setenv' in env.el in xemacs-base was synched to support jpw> a SUBSTITUTE-ENV-VARS argument, and a `substitute-env-vars' jpw> function was added to the file. Should 21.5's jpw> lisp/process.el get the same treatment ? Ben has a strong argument that many of the functions in libraries in xemacs-base should be in core. Eventually this duplication should be eliminated. For now I would say that if 21.5 works without those functions in core, we should comment them out and xref env.el in 21.5's process.el. Ben is authoritative on this, however. -- 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

Kyle> The reason to keep that stuff out of the core is that you Kyle> can make more frequent releases of packages that are Kyle> separate from the core. Agreed. You can probably guess just how much of a relief it is to me, and I bet to Vin, that Steve Y puts out new package releases at the rate he does. It takes a lot of pressure off! And Ben (AFAIK) is not in favor of making the core bigger, just putting the stuff he's working on, with strong implementation dependencies, in the core. I'm all in favor of throwing as much stuff out of core as we can, for exactly the reason you give.[1] However, as I see it, there are four practical problems. 1. Bootstrapping: you cannot currently build XEmacs and access packages remotely without the EFS and xemacs-base packages. We need a reliable bootstrap package transport in the core. We also need a bootstrap distribution which contains some of the basic packages useful in setting up XEmacs. 2. Closely related, is that the more stuff we move out of the core, the more essential stuff is going to be in packages. We are currently not set up to maintain a devel branch and a stable branch in packages, but we'll have to do so. The kinds of failures we've had with EFS on various platforms should be considered indicative of lurking problems in our setup if we try to move more essential functions to packages. 3. Some of the _functions_ (not whole libraries) in xemacs-base in particular, but also in packages like APEL and elib, really should be part of the core as they depend on implementation details in the core. We don't have a good way to document "this is core API, that is a packaged extension" at present. 4. We've done a pretty good job of eliminating shadowing issues as a major source of user bug reports. But if we're going to be throwing libraries over the wall into packages, we'll start getting them again. Ben has talked about an infrastructure for tracking problems like 3 and 4, but I don't know if he's done any of it. And fifth, who's gonna do all this work? IMHO, it's worth doing. Footnotes: [1] I think that Steve B was mostly too conservative when he did the separation. Eg, lisp-mnt belongs in xemacs-devel, not in the core, and the FAQ and PROBLEMS at least should be in separate packages, and NEWS, or at least ONEWS, as well---we now can make doc-only packages, I think that would have been hard back then. Later developers have continued in the tradition (there is zero need for gutter-items in the core, and except for the bootstrap transport, PUI should be packagized). -- 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