Re: [Lynx-dev] uxterm vs GNU screen weirdness

[Thorsten Glaser]

Thomas Dickey dixit:

>Not all terminals do this (support the vt100 controls in UTF-8
>mode

Yes, I knew about that; this is used as a pro-UTF-8 advertising argument:
it makes the terminal more robust against catting binaries.

>and not all of the characters are vt100 codes.  For the other cases,
>ncurses has to look in a table for the corresponding UTF-8 codes directly.

So this basically means that the current terminfo entries are indeed
correct, and there is no “sane” way to tell ncurses that these charac-
ters are supported, because ncurses is not the only user of the term-
info database (especially considering that it’s used to generate the
termcap database), and other programmes do not have this kind of look-
up table. (While them being not standard VT100, I can assume that tools
look for the existence of these characters in the termcap and use them
if they exist, but directly, using the C equivalent to my original ksh
print command.)

Conclusion: I’ll probably just add ‘hh’ to the database, or I’ll patch
uxterm to handle the additional characters (in utf-8 mode). Wait, no,
that’s not a good idea, in case someone on, say, Sourcemage GNU/Linux
uses xterm-xfree86 to login to MirBSD and does not have that patch.

Hmm. Ok, so no fancy arrows for me. (Unless upstream xterm (either
XFree86 or you) were to apply said patch.)

bye,
//mirabilos
-- 
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font.   -- Rob Pike in "Notes on Programming in C"