[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH]console:UTF-8 mode compatibility fixes

From: Thomas Dickey
Subject: Re: [PATCH]console:UTF-8 mode compatibility fixes
Date: Sat, 18 Feb 2006 20:53:38 -0500 (EST)

On Sat, 18 Feb 2006, Alexander E. Patrakov wrote:

[sorry for repost, the first attempt got blocked due to html attachment, now I gzipped it to circumvent the filter]

Adam Tla/lka wrote:
This patch applies to kernel sources to drivers/char/vt.c file.
It should work with other versions too.

Changed console behaviour so in UTF-8 mode vt100 alternate character
sequences work as described in terminfo/termcap linux terminal definition.
Programs can use vt100 control seqences - smacs, rmacs and acsc  characters
in UTF-8 mode in the same way as in normal mode so one definition is always
valid - current behaviour make these seqences not working in UTF-8 mode.

I expect some discussion from the people who _vehemently_ refused to allow
the Linux console to have anything that resembled a mode.

More to the point: since it's been in this form for several years, it doesn't do much good to developers, because there are already workarounds in ncurses to accommodate this, and even if you fixed it today, it would
be needed in ncurses for a few more years.

For example (man ncurses):

            During initialization, the  ncurses  library  checks  for  special
            cases  where  VT100  line-drawing (and the corresponding alternate
            character set capabilities) described in the terminfo are known to
            be  missing.   Specifically,  when  running in a UTF-8 locale, the
            Linux console emulator and the GNU screen  program  ignore  these.
            Ncurses checks the TERM environment variable for these.  For other
            special cases, you should set this  environment  variable.   Doing
            this  tells  ncurses to use Unicode values which correspond to the
            VT100 line-drawing glyphs.   That  works  for  the  special  cases
            cited, and is likely to work for terminal emulators.

            When  setting this variable, you should set it to a nonzero value.
            Setting it to zero (or to a nonnumber) disables the special  check
            for Linux and screen.

is the most recent refinement (from a year ago) to a workaround which first appeared in ncurses 5.4 (originally from December 2002).

Doesn't work here with linux-2.6.16-rc3-mm1, ncurses-5.5. BTW has this
been discussed with Thomas Dickey (ncurses maintainer)?

no (my seeing it via google doesn't count).

Another feature request / bug report (spotted while viewing in Lynx a
page containing English text and a few Chinese characters, artificial
testcase attached):

If ncurses attempt to add some Chinese character to the Linux text
screen, Linux (correctly) prints this replacement character and advances
the cursor by one position. Ncurses think that the cursor has moved two
positions forward. The effect is that when you view the testcase in Lynx
(compiled --with-screen=ncursesw) on Linux console and press PageDown,
the fourth line contains "Thek" instead of "The" in the end.

This disagreement has to be solved somehow.

yes.  ncurses has no better information for this than the result from
wcwidth().  Shall we add another kludge to accommodate Linux console?
(Are there other terminal emulators with this specific problem?)

Thomas E. Dickey

reply via email to

[Prev in Thread] Current Thread [Next in Thread]