Stephen J. Turnbull wrote:
>>>>>"Ben" == Ben Wing <ben(a)666.com>
writes:
>>>>>
>>>>>
Ben> currently we use 32-127 for the values of the chars in the
Ben> iso-8859 charsets. maybe that was needed under old-mule, but
Ben> in unicode-internal charsets can have values in any arbitrary
Ben> interval or rectangle in 256 or 256x256 space. shouldn't we
Ben> use 160-255? this would only matter in the output of
Ben> `split-char'; `make-char' already goes either way.
No. This is gratuitous incompatibility with ISO 2022, legacy X11 font
indexing, and other Emacsen. Why buy trouble changing a public API?
it's the other way around. the current situation is incompatible with
the X11 fonts, so we have to hack the values using the bogus `graphic'
characteristic.
note that in the new world, charsets can have values > 127 in any case.
cf. big5, shift-jis, etc.
so when i'm creating a new charset like `latin-windows-1252', which is
compatible with iso-8859-1 but has extra chars in the range 128-159, do
i do the right thing and have its chars in the range 128-255 be indexed
as 128-255 (and hence be inconsistent with the `latin-iso8859-1'
charset), or do i do the wrong thing and move its range down to 0-127?
and then it appears to have ascii control chars in the range 0-31, but
they aren't control chars, value 10 is not linefeed, value 13 is not cr,
etc.?
ben