Re: display table for eight-bit-graphic

[Kenichi Handa <handa@m17n.org>]

In article <E18dfi5-0003Mg-00@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:
>>  This way, people who don't like MULE and use Emacs in unibyte
>>  mode with European character sets get the same behavior as before.

>     I don't think so.  See this comment again:

> 	      ;; If default-enable-multibyte-characters is nil,
> 	      ;; we are using single-byte characters,
> 	      ;; so the display table and terminal coding system are irrelevant.

> Where is that comment?

It's in the function set-locale-environment (in mule-cmds.el).

> 	      (when default-enable-multibyte-characters
> 		(set-display-table-and-terminal-coding-system language-name))

>     It seesm that the intention is to use the display table for
>     multibyte buffers.

> It is definitely intended to use the display table for multibyte
> buffers--but I think that's not actually the issue you are talking
> about.

I'm talking that using the display table in multibyte
session is not good.

> Anyway, I don't think this actually contradicts anything I said.
> The display table is used for unibyte buffers, too.  If we
> want unibyte buffers to display the international graphics,
> we have to set up the display table for codes 128-255.

We don't have to use the display table even for unibyte
buffers.  Even for a unibyte buffer,
get_next_display_element in xdisp.c doesn't generate a octal
form "\XXX" for a code in the range 128-255 if the code can
be converted to a multibyte character by
unibyte_char_to_multibyte.

So, such a code is given to x_produce_glyph as is.  Then, in
x_produce_glyph, if unibyte-display-via-language-environment
is nil, that code is used as is (thus is displayed by the
default font), otherwise, that code is converted to a
multibyte char (thus is displayed by a font selected from
the current fontset).

In short, both in multibyte and unibyte sesseion, there's no
need of setting the display table now.

---
Ken'ichi HANDA
handa@m17n.org