Re: FLIM 1.14.5 bug-fix

KY> In principle, APEL does never redefine existing functions KY> having no problems, In practice in XEmacs it regularly does. We should build APEL under 21.1 (in practice I think we're actually building under 21.4), or some packages depending on APEL may not run on 21.1, because APEL decides what to provide at compile time, not at load time. This means that anything added or fixed in 21.4 or 21.5 gets redefined by APEL. We could of course just remove APEL and everything it depends on from the packages and tell the users to build their own. This is better for the users, but rather annoying for the developers. Or we could rebuild APEL for each version of XEmacs, but aside from being extra work for Norbert, this would be hard to make work in installations providing multiple versions of core XEmacs. KY> but it fixes bugs in old function definitions, emulates KY> functions which aren't available in old Emacsen, ... Right. So that means when I do C-x C-e on the sexp provided by the (non-APEL-using) Original Poster, if APEL has been installed in my XEmacs I will see up-to-date interfaces and behavior, and typically if I then do C-x f on the function, it looks like the version distributed in core XEmacs because it doesn't get defun'ed by APEL, instead the function cell is set directly. ISTR that APEL even replaces subrs in the function cell of some symbols without saying so in the docstring. This is very confusing when debugging. All this could be fixed either in APEL or in XEmacs, but I think it would require a fair amount of work either way. -- Institute of Policy and Planning Sciences 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.