FLIM 1.14.5 bug-fix

[Katsumi Yamaoka]

>>>>> In <87d6h1gm50.fsf at tleepslib.sk.tsukuba.ac.jp>
>>>>>	"Stephen J. Turnbull" <stephen at xemacs.org> wrote:

KY> In principle, APEL does never redefine existing functions having
KY> no problems,

> In practice in XEmacs it regularly does.

Yep, my recognition was possibly lacking.

> 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.

I was really often troubled with the problem (since I'm now using
only 21.4, I tend to forget it, though).  It is mainly caused by
the def*-maybe macros which switch function definitions at the
compile time.  Although it was probably a rational technique for
early days, it is not suitable to the XEmacs package.  In
addition, def*-maybe began to be abused by other programs.

I and Shuhei KOBAYASHI used to try to overcome the problem.  The
plan was to make def*-maybe macros switch function definitions
at the load time by default.  The code already exists in the
branch of cvs.m17n.org, but it is not fully verified.

> 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.

Is there any XEmacs package using APEL actively?  It seems to be
very few to me.  I think separating APEL from XEmacs is good
idea even though I am one of the APEL developers.

KY> but it fixes bugs in old function definitions, emulates functions
KY> 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.

I sometimes want to keep away from APEL for the same reason.

> All this could be fixed either in APEL or in XEmacs, but I think it
> would require a fair amount of work either way.

It will be easier to abolish APEL from XEmacs.  I am writing so
in the hope that other APEL developers bring counterargument. :p
-- 
Katsumi Yamaoka <yamaoka at jpl.org>