[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Display slowness that is painful
From: |
Kenichi Handa |
Subject: |
Re: Display slowness that is painful |
Date: |
Tue, 07 Feb 2006 10:41:06 +0900 |
User-agent: |
SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/22.0.50 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) |
In article <address@hidden>, Andreas Schwab <address@hidden> writes:
> Apparently the conversion to multibyte is broken in some way. In the
> normal case, when unibyte-display-via-language-environment is nil, no
> non-ascii character are ever used for display, so it works as expected.
I found what is wrong. There are two problems related to
this bug.
At first, when running on a terminal, produce_glyphs is
called instead of x_produce_glyphs, but
unibyte-display-via-language-environment is handled only in
x_produce_glyphs. So, I've just installed a fix of this
problem. It at least fixes messing up of display as far as
your terminal and Emacs agree with terminal coding system.
Next, even in utf-8 environment, on displaying, emacs
converts unibyte characters of the range 0xA0..0xFF to some
multibyte characters if
unibyte-display-via-language-environment is non-nil.
Theoretically, as utf-8 doesn't use single byte for
non-ASCII characters, such a conversion should not be done.
But, that conversion has been done for many (7 or more)
years, and now is not a good time to change that code.
---
Kenichi Handa
address@hidden
Re: Display slowness that is painful, Andreas Schwab, 2006/02/01
Re: Display slowness that is painful, Richard M. Stallman, 2006/02/01
Re: Display slowness that is painful, Richard M. Stallman, 2006/02/01