On Mon, 2002-07-15 at 06:41, Katsumi Yamaoka wrote:
> >>>>> In [apel-en : No.00015]
> >>>>> Ville Skyttä <ville.skytta(a)xemacs.org> wrote:
>
> > this patch to APEL was sent to xemacs-patches(a)xemacs.org, and has
> > already been committed to XEmacs CVS. Please consider applying in APEL
> > CVS too.
>
> Thank you very much for the forwarding. The patch is correct,
> but...
>
> > From: Daiki Ueno <daiki(a)xemacs.org>
> > To: Adrian Aichner <adrian(a)xemacs.org>, xemacs-patches(a)xemacs.org
> > Subject: [PATCH] packages: Define encode-mime-charset-string as function
> > Date: 13 Jul 2002 18:36:56 +0900
>
> > I think this is a bug of APEL. The background is that Liece uses
> > encode-mime-charset-string, the function is defined seperately in APEL
> > (for MULE and non-MULE), and the version for MULE calls
> > mime-charset-to-coding-system with the second argument. Unfortunately
> > if the package is compiled for MULE, encode-mime-charset-string is
> > inlined into bytecode here:
>
> The problem arises from the difference between the intention of
> the developers on APEL and the management policy for the XEmacs
> packages. In my interpretation, all emulating functions and
> utility functions in APEL will be provided for the particular
> version of Emacs in principle, e.g. specialize for Emacs 18.59,
> specialize for XEmacs 21.5-b7, etc. It is aimed at a high
> performance, not a portability. So, the APEL developers require
> user to compile and install APEL for each version of Emacs one
> by one. For instance, if APEL provides the function
> string-to-char-list supposing that it only exists in XEmacs 21.4
> and earlier as follows:
>
> (defun-maybe string-to-char-list (str)
> (mapcar #'identity str))
>
> The byte-code for this function will never be produced if the
> XEmacs APEL package is compiled with XEmacs 21.4. What should
> XEmacs 21.5 users do?
>
> It seems that there are three choices for the future XEmacs:
>
> 1. Put APEL in each version of the XEmacs core.
>
> 2. Leave APEL out of the XEmacs packages. Users who need to
> have APEL should install it by themselves.
>
> 3. Rewrite all the APEL modules in order to have a portability
> at the sacrifice of a performance.
IMHO, any of these choices doesn't sound too good. Would this one work?
4. Provide the XEmacs apel package without byte-compiled files.
--
\/ille Skyttä