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

[Katsumi Yamaoka]

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

Regards,
-- 
Katsumi Yamaoka <yamaoka at jpl.org>