Re: raw-byte and char-table

[Kenichi Handa <handa@m17n.org>]

In article <8362z0ndke.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> > > >   (aref CHAR-TABLE (unibyte-char-to-multibyte #xA0))
> > > >   (aset CHAR-TABLE (unibyte-char-to-multibyte #xA0) VALUE)
> > 
> > > One could also use the codepoint of the corresponding eight-bit
> > > character directly, no?
> > 
> > Like #x3FFFA0?  It's possible but should not be recommended.

> Why not recommended?  We already document in the ELisp manual the
> codepoints to which we map eight-bit bytes.  It's not a secret, it's
> in the open.

Number like #x3FFFA0 is so criptic.  The function name
unibyte-char-to-multibyte is also not ideal, but I think
it's better than #x3FFFA0.

> > As for a display table, we have one more problem.  Currently
> > an element of a display table is nil or a vector of
> > characters.  To directly output the byte #xA0 to a terminal,
> > perhaps the correct way is to set (unibyte-char-to-multibyte
> > #xA0) in a vector.  That way, we can specify any byte(s) to
> > send to a terminal.
> > 
> > But, then, what is the semantics of the vector element
> > (unibyte-char-to-multibyte #xA0) for a graphic device?  What
> > should we display for CHAR if we setup
> > standard-display-table as this?
> > 
> >   (aset standard-display-table 
> >         CHAR (vector (unibyte-char-to-multibyte #xA0)))

> There's something I'm missing here: why text terminals and graphics
> terminals are different in this context?  It seems that you are saying
> that was is correct for a text terminal does not have a clear
> semantics for a GUI terminal,

Yes.

> but why?

What we can send to a terminal is a byte.  So, by having a
method of specifying any raw byte directly, we can send all
possible bytes to a terminal.  For a graphic device, the
natural interpretation corresponding to "directly sending a
raw byte" is, I think, "directly specifying a glyph code".
But, to specify all possible glyph codes, 0x80..0xFF is not
enough.

---
Kenichi Handa
handa@m17n.org