emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: raw-byte and char-table


From: Kenichi Handa
Subject: Re: raw-byte and char-table
Date: Tue, 24 Aug 2010 13:29:45 +0900

In article <address@hidden>, Eli Zaretskii <address@hidden> writes:

> > A char-table is a table indexed by a character code.  So,
> > it's 0xA0th element is a value for a character U+00A0.
> > Then, how to set/get a value for raw-byte 0xA0?  Currently,
> > this is the way to do that:
> > 
> >   (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.

> I mean, unibyte-char-to-multibyte is just the
> way of getting that codepoint, right?

Yes.

> > But, this is not documented.  Should we document it?

> Yes, IMO.

> > Should we change the above code and all other codes setting
> > 0x80th..0xA0th elements of a display table?

> Yes.  IMO, we should consistently use the codepoints of eight-bit
> characters in all char-tables.

Ok, if Yidong and Stefan agree too, I'll work on it.

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)))

It seems that displaying a glyph of glyph-code 0xA0 of a
font that is usually selected for CHAR is the most natural
interpretation.  But then, it means that we have a method of
directly specifying a glyph-code only if it is 0x80..0xFF;
it's very unbalanced.

---
Kenichi Handa
address@hidden



reply via email to

[Prev in Thread] Current Thread [Next in Thread]