Re: Ethiopic in 21.1.7++
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
>>>>> "Jan" == Jan Vroonhof
<vroonhof(a)math.ethz.ch> writes:
Jan> Vin Shelton <acs(a)xemacs.org> writes:
>> Symbol's function definition is void:
>> setup-ethiopic-environment-internal
>>
>> I'd like to get this working before I release 21.1.8 (tonight,
>> I hope). Can anyone offer a patch?
This looks like the same thing that was happening with Japanese and
some other languages. The FSF changed the language environemnt API,
and that got ported to a couple of language environments but not
the rest. :-(
Like Jan said, it must not be Symbol's function definition
is void error since it is defined at ethio-util.el Maybe Vin
hasn't installed mule-base? However, it requires
exit-function handling to be implemented in
setup-language-environment so it is problematic to use code
in ethio-util.el (it defines f2, f3 and other keys so after
setting up Ethiopic language environment in XEmacs 21.1, the
original definition of those keys won't be recovered).
Jan> I tried making the obvious path (namely copying
Jan> 'setup-ethiopic-environment-internal from an old mule base
Jan> into the core), however then I stopped. auto-autoloads.el
Jan> from mule-base contains
Ethiopic is one of the things that got ported from FSF and ignored, I
think disabling it is the best route until somebody is willing to take
a good look at it.
I think so, too. Until someone who knows Ethiopic is going
to use and test it, removing Ethiopic support would not
hurt.
That is my suggestion for any non-ISO-8859, non-Asian-ideographic
language that breaks, unfortunately. I think a real solution to this,
one that is robust to ++patchlevel, even, will have to wait until we
define real APIs for Mule and convince porters from FSF to stick to
them.
Yes, we need APIs.
--
Yoshiki Hayashi