Hello Micah, and welcome on board, On Thursday, June 19, 2008 at 16:58:39 -0700, Micah Cowan wrote:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=144178 >> screen only understands \E(0 and \E(B. It also emits these sequences >> to instruct the terminal its running in to move in/out of the ACS. Not exactly: - Screen understands ^N/^O once it has been correctly initialised by enacs=\E(B\E)0. Of course box drawing apps are expected to send enacs once, at the beginning, before any smacs/rmacs. - Screen then translates ^N/^O to the underlying terminal's smacs/rmacs, whatever they are, and sends this translation. >> with TERM=xterm, as infocmp shows that the correct sequences for this >> terminal type are ^N/^O. Bizare. In the latest terminfo from 2008-04-29: | $ infocmp -1 xterm | grep acs= | rmacs=\E(B, | smacs=\E(0, > [Micah] My response: >> the fault is in the terminfo description for screen. Let's see: | $ infocmp -1 screen | grep acs= | enacs=\E(B\E)0, | rmacs=^O, | smacs=^N, This looks perfectly right to me, and should work. I don't understand the original problem, or rather the reported facts don't seem to be a problem. >> in UTF-8 mode, screen apparently uses the Unicode box characters, >> rather than the parent terminal's smacs feature. Some UTF-8 terminals don't accept mode changes, on the principle that UTF-8 is modeless. That's why all applications drawing boxes have to special case UTF-8... Screen does the job for the few poorly written apps not doing it themselves. Bye! Alain. -- Unicode Integrism? See the archives for more discussion on why this should, like hydrogen for dirigibles, be relegated to the past. PCC DTG on MU. © August 2004.
