[Fwd: [PATCH] packages: Define encode-mime-charset-string as function]

[Ville Skyttä]

On Mon, 2002-07-15 at 06:41, Katsumi Yamaoka wrote:

> >>>>> In [apel-en : No.00015]
> >>>>>	Ville Skyttä <ville.skytta at xemacs.org> wrote:
> 
> > this patch to APEL was sent to xemacs-patches at 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 at xemacs.org>
> > To: Adrian Aichner <adrian at xemacs.org>, xemacs-patches at 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ä