FLIM 1.14.5 bug-fix

[Stephen J. Turnbull]

>>>>> "KY" == Katsumi Yamaoka <yamaoka at jpl.org> writes:

    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.