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

[Kenichi Handa]

I'm sorry for this late response on this thread.

In article <address@hidden>, Jesper Harder <address@hidden> writes:
>>>  By the way, the node "(elisp)Active Display Table" states that the
>>>  default value for `standard-display-table' is nil.
>> 
>>  Right.  How about writing the info as below?
>> 
>>  This variable's value is the default display table, used whenever a
>>  window has no display table and neither does the buffer displayed in
>>  that window.  This variable is usually @code{nil}, but set to a
>>  proper display table when Emacs is started in such locales that use
>>  a single byte character set (e.g. en_US.iso88591).

> I'm still a bit confused about _why_ the display table should be
> non-nil in a single byte locale.

> 8bit characters like æøå display just fine for me if
> `standard-display-table' is nil (both in X and on a console).

Actually, the relevant codes were written by someone while I
was too busy to work on Emacs.  So, I myself don't really
understand the underlining idea of those codes.

We must consider these parameters for displaying:
  * multibyte mode or unibyte mode
  * on terminal or on a windowing system
  * on Unix-like system, on MS-DOS, or on MS-Windows.
This yields 8 cases (because some conbinations are invalid).

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?

---
Ken'ichi HANDA
address@hidden