Re: [PATCH] fix for (list-coding-systems) from mule-diag.el

Ben> speaking of this ... long ago i realized that xemacs-base Ben> and mule-base definitely belong in the core, not as packages. What's the rationale? Is it just the build and runtime problems due to missing libraries when bootstrapping, or is it something else? Ben> what do others think of this? I'm not sure. Many of those files do not implement "core" functionality (eg, canna.el and mule-diag.el), and can use standard APIs as documented in Lispref. Certainly, it's annoying to have build problems (eg, Norbert Koch's make check failures) because commonly used libraries are in packages. But I think it's better to fix that problem by having a subset of packages distributed with XEmacs sources, and keep the logical distinction between "core" libraries (which are implemented via internal APIs we reserve the right to change on a whim) and "package" libraries, which use only public APIs. I don't know how to implement this for CVS, though, or if it even needs to be. I have thought about it for the tarballs. Note that it is not a problem for the netinstaller. -- 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."