Re: address@hidden: `set-locale-environment' bug]

[Kenichi Handa]

In article <address@hidden>, "Eli Zaretskii" <address@hidden> writes:
>>  But, in multibyte-mode, it seems that only MS-DOS case (on
>>  terminal) really requires standard-display-table to be
>>  setup.  That is because, in that case, characters in the
>>  current codepage that are not supported by Emacs are decoded
>>  into eight-bit-control/graphic, and they must be displayed
>>  by the font of the current codepage as is.
>>  
>>  Eli, is that right?

> Yes and no.

> No, because unsupported characters are not displayed as the current
> codepage's glyphs, they are displayed as a special glyph whose value
> is in `dos-unsupported-char-glyph'.

> Yes, because term/internal.el, the MS-DOS ``internal terminal''
> emulator, sets up standard-display-table to display non-ASCII
> characters beyond the current codepage, such as Latin-2 for a cp-850
> locale, as strings of ASCII characters, see IT-display-table-setup.

Thank you for the explanation.  It seems that all settings
about display table and terminal coding system is done by
dos-codepage-setup via term-setup-hook.  So, mule-cmds.el
should do nothing for them on DOS, right?

> I think in the past standard-display-table was used on multibyte
> sessions on Unix as well, to map some characters originating from
> Microsoft's codepages to printable ASCII chars, but I'm not sure
> whether I remember correctly and if so, why was that removed.

I think we must think over making the code in mule-cmds
clearer now.  The current code is quite confusing and it
seems that there are bugs.

For instance, at starup time,
set-display-table-and-terminal-coding-system is called in
this way now:

command-line ->
  set-local-environment ->
    set-language-environment ->
      set-display-table-and-terminal-coding-system (in unibyte mode only) ->
    set-display-table-and-terminal-coding-system (in multibyte mode only)

And set-display-table-and-terminal-coding-system calls
standard-display-european-internal in a lang. env. that has
`unibyte-display' setting, and resets standard-display-table
for 8-bit chars otherwise.

So, for instance, if we start in some European locale in
multibyte mode, standard-display-european-internal is
called, but when we switch to Japanese lang. env., the
standard-display-table is not reset.  On the other hand, if
we start in Japanese locale in multibyte mode, even if we
switch to some European locale,
standard-display-european-internal is not called.

But I need more time to study the current code to give a
concrete proposal for solving it.

---
Ken'ichi HANDA
address@hidden