Re: Ethiopic in 21.1.7++
I did not have mule-base installed when I ran my very simple test of
attempting to set each language environment one at a time. None of
the other language environments gave me a problem, BTW.
- vin
>>>> On 09 Nov 1999, Yoshiki Hayashi
<t90553(a)m.ecc.u-tokyo.ac.jp> said:
Yoshiki> "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. :-(
Yoshiki> Like Jan said, it must not be Symbol's function definition
Yoshiki> is void error since it is defined at ethio-util.el Maybe Vin
Yoshiki> hasn't installed mule-base? However, it requires
Yoshiki> exit-function handling to be implemented in
Yoshiki> setup-language-environment so it is problematic to use code
Yoshiki> in ethio-util.el (it defines f2, f3 and other keys so after
Yoshiki> setting up Ethiopic language environment in XEmacs 21.1, the
Yoshiki> 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.
Yoshiki> I think so, too. Until someone who knows Ethiopic is going
Yoshiki> to use and test it, removing Ethiopic support would not
Yoshiki> 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.
Yoshiki> Yes, we need APIs.