[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev Emacs + UTF-8 + Lynx
From: |
Sergei Pokrovsky |
Subject: |
Re: lynx-dev Emacs + UTF-8 + Lynx |
Date: |
28 May 2000 13:49:25 +0700 |
User-agent: |
Gnus/5.0806 (Gnus v5.8.6) Emacs/20.6 |
>>>>> Thomas Dickey writes:
Thomas> On Sat, May 27, 2000 at 03:17:03PM +0700, Sergei Pokrovsky
Thomas> wrote:
...
>> The situation is worse with the stand-alone xterm.
>>
>> After I've installed xterm, I've got a nice colored display,
>> which rendered most of UTF-8 almost correctly when called with
>> -u8 (except for the 0x80 bit bytes mentioned earlier).
Thomas> I didn't notice the mention of the 0x80
Klaus Weide mentioned it on May 26, Message-ID:
<address@hidden>:
Klaus> Note the common pattern: in both cases, the UTF-8 encoding
Klaus> contains a 0x80 byte. Possibly this byte value triggers some
Klaus> error, either in emacs' terminal emulator or in the curses or
Klaus> slang library your lynx binary is using. I don't think the
Klaus> error is in the lynx code, it's hard to see why it would get
Klaus> just that byte value wrong (and if it's lynx itself, I should
Klaus> see the error, too.)
>> Than I've installed the ncurses, having supplied the ./configure
>> script with --enable-widec (maybe that was an error?).
Thomas> no - it's ok. But the resulting ncurses library is not
Thomas> compatible with applications that may have been compiled
Thomas> previously.
OK, I've recompiled xterm.
...
>> Now the Unicode characters are rendered better in xterm -u8, the
>> Russian small R no longer misbehaves, I do see em-dash.
>>
>> *But*
>>
>> 1) The fi ligature is rendered as a box in the anchors (see the
>> anchor
Thomas> I'll look at this. I'm not sure whether a box is a
Thomas> character that does not appear in the font, or if it is a
Thomas> multi-plane character (requires merging of 2 or more Unicode
Thomas> values). There is an experimental patch to handle that, but
Thomas> I've not integrated it yet (it needs more work).
The problem is gone away after the rebuild.
...
>> 2) Lynx has lost the colors.
Thomas> This is a symptom of the incompatibility that I mentioned.
Thomas> The bits in a chtype that represent color are shifted by 8
Thomas> bits. The bold and underlining, etc., also are shifted.
Yes, now this is OK as well.
--
Sergei
; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden
- lynx-dev Emacs + UTF-8 + Lynx, Sergei Pokrovsky, 2000/05/25
- Re: lynx-dev Emacs + UTF-8 + Lynx, Thomas E. Dickey, 2000/05/25
- Re: lynx-dev Emacs + UTF-8 + Lynx, Sergei Pokrovsky, 2000/05/26
- Re: lynx-dev Emacs + UTF-8 + Lynx, Klaus Weide, 2000/05/26
- Re: lynx-dev Emacs + UTF-8 + Lynx, Sergei Pokrovsky, 2000/05/27
- Re: lynx-dev Emacs + UTF-8 + Lynx, Thomas Dickey, 2000/05/27
- Re: lynx-dev Emacs + UTF-8 + Lynx,
Sergei Pokrovsky <=
- Re: lynx-dev Emacs + UTF-8 + Lynx, Thomas Dickey, 2000/05/28
- Re: lynx-dev Emacs + UTF-8 + Lynx, Klaus Weide, 2000/05/28
- Re: lynx-dev Emacs + UTF-8 + Lynx, Thomas Dickey, 2000/05/28
- Re: lynx-dev Emacs + UTF-8 + Lynx, Klaus Weide, 2000/05/28
- Re: lynx-dev Emacs + UTF-8 + Lynx, Thomas Dickey, 2000/05/28
- Re: lynx-dev Emacs + UTF-8 + Lynx, Klaus Weide, 2000/05/28
- Re: lynx-dev Emacs + UTF-8 + Lynx, Thomas Dickey, 2000/05/29
- Re: lynx-dev Emacs + UTF-8 + Lynx, Klaus Weide, 2000/05/28
- Re: lynx-dev Emacs + UTF-8 + Lynx, Sergei Pokrovsky, 2000/05/28
- Re: lynx-dev Emacs + UTF-8 + Lynx, Thomas Dickey, 2000/05/28