KY> If you don't mind it, please re-install APEL. APEL is to be avoided if possible. It makes debugging hard because it redefines many functions without leaving any trace in the docstring. For one function, it's best to add the function. -- 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.

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.

KY> In principle, APEL does never redefine existing functions having KY> no problems, Yep, my recognition was possibly lacking. 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. 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, ... I sometimes want to keep away from APEL for the same reason. 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(a)jpl.org&gt;

KY> Is there any XEmacs package using APEL actively? 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. 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 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(a)jpl.org&gt;