FLIM 1.14.5 bug-fix

[Katsumi Yamaoka]

>>>>> In [emacs-mime-en : No.00098]
>>>>>	"Stephen J. Turnbull" <stephen at xemacs.org> wrote:

KY> Is there any XEmacs package using APEL actively?

> Only packages from Mule AFAIK.

I found liece, skk and tm used APEL.  Although I don't know
whether liece has been abolished by the author, liece has grown
into riece quite recently and only the ptexinfmt.el module use
APEL there.  I've already made ptexinfmt.el which doesn't
require APEL for emacs-w3m.  skk surely uses APEL deeply,
however it seems not to have been maintained by the original
development team.  The mainstream exists in the
openlab.ring.gr.jp CVS server.  Are there any people who are
still using tm?

I think all those packages are useless.  Do someone have a
counterargument? (skk folks?)  In addition, that SUMO contains
old APEL has a bad influence on other packages, e.g. Wanderlust,
T-gnus, etc. which require new APEL.  So, we need to write
"remove it" in the FAQ list.

> However, there has been a lot of discussion recently about
> compatibility packages so that users could easily load new functions
> judged "too risky" to put into the stable branch.

> APEL would give a huge head start on that if (1) you could choose what
> you want to load (ie, a variable to inhibit loading or force APEL to
> ask if a module should be loaded) and (2) either APEL was changed to
> document what it's doing (eg, the way advice.el does) or XEmacs was
> changed to detect APEL activity in its help functions.  ISTR that APEL
> never throws away old definitions, it stashes them in the property
> list.  If so, it would be possible for C-h f and friends to check for
> those properties and warn "this function was APEL-ized."

Could you show an example?  What function is redefined?  skk
uses defadvice for many basic functions, but it is not related
to APEL.  I think putting "This function is defined by APEL."
into the docstring is a good idea if a function is provided anew
by APEL.

KY> It will be easier to abolish APEL from XEmacs.  I am writing so
KY> in the hope that other APEL developers bring counterargument. :p

> APEL as currently known, yes.  But compatibility libraries are
> something that we should provide.  APEL is quite comprehensive and
> generally good code; it's just the side effects I don't like.

I'm not sure whether XEmacs really needs APEL.  But it seems
useful to provide the module to keep compatibility of packages
through 21.1 to 21.5.
-- 
Katsumi Yamaoka <yamaoka at jpl.org>