Ar an t-ochtú lá is fiche de mí Deireadh Fómhair, scríobh Ben Wing:
> Ben> currently we use 32-127 for the values of the chars
> 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'
It remains incompatible with ISO 2022 and other Emacsen, and will break
note that in the new world, charsets can have values > 127 in any
cf. big5, shift-jis, etc.
so when i'm creating a new charset like `latin-windows-1252', [...]
Create another API for character sets in that 256 char or
rectangle-of-256x256-char space, then. Breaking the old API doesn’t buy a
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.?
Another reason to create another API; it would be possible to implement
EBCDIC character sets with one that didn’t assume ASCII compatibility, as
the existing API does. With an API that didn’t suck,
(make-char-alternative code-page-037 #x40)
(make-char-alternative code-page-037 #xc0)
could and should mean different things.
„Frauen achten mehr aufs Herz und weniger auf Dummheiten. Darum leben sie
länger.“ (C.R. Zafón -- Übertragung von Peter Schwaar.)