Thu 19 Jun 2008 11:45:40 PM UTC, original submission:
My analysis from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=144178:
It looks to me as if the fault is in the terminfo description for screen.
Screen does in fact understand ^N/^O, and processes them according to ISO-2022. It does not simply pass them through, but rather processes them itself, to invoke the G1 character set to GL.
However, screen's default value for "charset" is "BBBB02", which uses US-ASCII as the G1 character set. Setting it to "B0BB02" uses the box-drawing characters for G1, which would cause ^N/^O to behave as you expect them to (and would render the terminfo description accurately).
Another way to invoke the box-drawing character set to G1 would be:
(Note the ')', rather than '(').
That would cause no immediately visible change, but ^N/^O would start working as you expect.
Note that, if you're running in UTF-8 mode, screen apparently uses the Unicode box characters, rather than the parent terminal's smacs feature.
So, to sum up, either the terminfo description (and screen's $TERMCAP) should specify '\E(0' / '\E)B', or else screen should default to "B0BB02" for the value of "charset".
|