On Sun, Feb 03, 2002 at 06:55:23PM +0000, Markus Kuhn wrote: > Thomas Dickey wrote on 2002-02-03 16:28 UTC: > > > Er, xterm shouldn't honor ACS controls in UTF-8 mode. One of the reasons I > > > like UTF-8 as a terminal encoding is that they don't explode if I accidentally > > > dump random binary data to it, which I tend to do at least once a day. :) > > > > hm (doesn't explode). > > When I execute in the UTF-8-mode xterm [XFree86 4.0.1h(149)] of Red Hat > 7.1 in a shell the line > > printf '\x1b(0' > > then xterm changes the Unicode values U+0020 to U+007E to the DEC > graphics character set, even though it is supposed to ignore ISO 2022 > sequences while being in UTF-8 mode, because UTF-8 is one of the > "encodings outside ISO 2022" in the sense of ISO 2022. > > Has this bug been fixed in more recent versions of xterm?
It seems the problem is that terminfo has no real way to deal with these sequences. That is, if I'm in UTF-8, then my terminfo caps acsc, enacs, smacs, and rmacs need to be changed. Terminfo can't simply blindly change what it returns for these sequences because the locale charset is UTF-8; there's a chance the library is being used to simply read caps (ie. infocmp). (The basic problem is that there's nothing in the terminfo API to handle this interaction between terminfo entries and the locale. It could be handled at a higher level--completely within ncurses--but then terminfo would still be returning incorrect information.) This needs to be sorted out before terminal emulators can drop these codes when in UTF-8 mode, since doing the latter first means breaking line drawing characters for all terminfo/ncurses/slang apps. -- Glenn Maynard -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
