Re: lynx-dev Emacs + UTF-8 + Lynx

[Klaus Weide]

On Sun, 28 May 2000, Thomas Dickey wrote:

> ok.  This is a different context from my changes to ncurses - lynx is
> displaying UTF-8 without assuming that the screen library knows about
> that.

Yeah, works quite well some of the time.  Or most of the time, depending
on circumstances and expectations...

> The limitation is that repainting the screen will not necessarily
> work, since a code that expands to multiple bytes may match the first
> byte or so of the previous (different) code at that location.

What you describe is basically the same problem that CJK output has.
Cf. recent patch for display_page.  The secret to making it work
better is: prevent partial updates (or at least: partial writes
of lines). I.e. clearok() and refresh() often.  (Or at least:
wredrawln or similar).

But UTF-8 has *more* problems than CJK.  In CJK (at least as far
as lynx handles it well), number of bytes == number of glyph cells.
That's not the case for UTF-8.

> I think that's part of what Klaus is referring to.

Not really... I was assuming that some (non-ncurses) curses had
problems with the byte value 0x80 in character output.

> good.  My patch for last night makes libncurses build as libncursesw
> for this configuration.

I was able to see all characters that Sergei had problems with (at
some stage) correctly, using either a pre-5.0 ncurses or slang[*], in
not-quite-the latest xterm  (Debian package xterm 3.3.4-0slink2,
has up to Patch '#113 - 1999/8/15 - XFree86 3.9.15b' according to
the changes.html that came with it).

[*] But some versions of slang have a bug that can mess up UTF-8
display with the current code - should be fixed in latest slang
version - see <http://www.debian.org/Bugs/db/62/62771.html>.

   Klaus


; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden