>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)srce.hr> writes:
Hrvoje> "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
> However ... shouldn't we be pedantic and restrict the
feature
> to ASCII? Nothing over ?\x7F is remotely portable across
> character encodings
Hrvoje> We lose nothing by allowing Latin 2 this way. The
Latin *2*? You mean in a Latin-2-font-using (no-Mule) XEmacs? How do
you distinguish in Mule? Or do you mean allowing it for Latin *1* as
a special case is OK?
>>>> "Jan" == Jan Vroonhof
<vroonhof(a)math.ethz.ch> writes:
Jan> "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
> However ... shouldn't we be pedantic and restrict the
feature
> to ASCII?
Jan> The problem is what to do with stuff like x-iso8859-1.el
Jan> then.
It should be Mule-ized. I don't have a problem with doing that in an
8-bit XEmacs, but in a Mule XEmacs such a Latin-1 bias is (in
principle) unacceptable. Politically a compromise may need to be
made, of course. It should be possible to have x-iso8859-2.el etc as
a trivial modification of x-iso8859-1.el; at present it is not.
I find it hard to imagine that there will be (character) keysyms
outside the repertoire of Unicode; doing it all through Unicode in a
Mule XEmacs should be the way to go. Then that file could be
generalized. Actually, it could be split into a set of nomule
versions similar to the current x-iso8859-1.el but in various 8-bit
encodings, and a mule version based on keysym to Unicode mappings, and
a `(require 'x-keysym)' would grab the appropriate one depending on
the hardware environment if `(not (featurep 'mule))'.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
__________________________________________________________________________
__________________________________________________________________________
What are those two straight lines for? "Free software rules."