Bug#550701: tmux does not support screen-256color like it claims
On Sun, Oct 25, 2009 at 01:51:33AM +0100, Nicholas Marriott wrote: On Sat, Oct 24, 2009 at 07:42:26PM -0400, Thomas Dickey wrote: well... if you're using terminfo to tell the number of colors (256 for example), it's a reasonably safe assumption that xterm supports both the aixterm (16-color) and 256-color controls. Unless of course the $TERM is set incorrectly, in which case the 256-colors is suspect. For other terminals, the 16-color feature was used - which accounts for the 16color variants. Yes, I can make that assumption but I'd have to bypass terminfo and output the 9x and 10x codes directly and I'm reluctant to add another case where I do that. I suppose it wouldn't do any harm, maybe I'll give it a go. I'd do that (there aren't a lot of different failure modes here). With latest terminfo I could say that any terminal with colors=256 has a setaf/setab that correctly accepts all 256 colours, then use setaf/setab instead of sending \\033[38;5;c directly to get the benefit of any optimisations in terminfo, but that isn't a safe assumption with an older terminfo.src :-/. I'm not sure why - from what I'm reading the only problem was that tmux didn't recognize the aixterm codes. Yes, that problem is fixed, but I was thinking it would be nice to get the optimisation automatically using setaf/setab. Unfortunately, until very recently OpenBSD did this: $ TERM=xterm-256color tput setaf 10|cat -v; echo ^[[310m I did see that, didn't need to followup (since it was found in the context of the bug-fix). When we added 256-/88-colors, it wasn't apparent that SGR parsing would be a problem... I thought it was fixed by using a newer terminfo.src (sorry) but checking again it is actually fixed by a separate OpenBSD bug fix just a few weeks ago. Anyway because of this tmux bypasses terminfo and just sends \\033[38;5;c directly and I am stuck with that at least until my fix gets into a couple of releases (or I #ifdef __OpenBSD__ it in tmux). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpMeMRugHdbr.pgp Description: PGP signature
Bug#550701: tmux does not support screen-256color like it claims
On Sat, Oct 24, 2009 at 07:20:28PM +0200, Nicholas Marriott wrote: On Sat, Oct 24, 2009 at 12:49:31AM +1100, Tim Allen wrote: On Fri, Oct 23, 2009 at 01:24:00PM +0100, Nicholas Marriott wrote: It appears screen-256color converts colours 8-15 into 90-97 which are an extension designed to allow bright colours without the bold attribute (bold font). Looking at xterm's ctlseqs.pdf, it refers to these 90-97 and 100-107 codes as aixterm codes; I suppose before xterm invented the 88- and 256-color hack, IBM had their own ideas about how to extend ECMA48 beyond 8 colours. Yes, I know, but the question is why does terminfo bother itself converting 8-15 to 90-97 when it could just pass it through and get the same result since 90-97 are the same as 8-15 in the 256-colour palette. setaf/setab used to use the standard ANSI SGR sequence in xterm- and screen-256color, the change to use the 256-colour extension is relatively recent. as noted in terminfo.src # 2006-06-24 ... # * improve xterm-256color by combining the ibm+16color setaf/setab # strings with SGR 48. The setf/setb strings also are cancelled here # rather than omitted so derived entries will cancel those also -Alain # Bench The improvement reduces the number of characters sent. Colors 8-15 use the aixterm SGR (which isn't ANSI SGR). Since aixterm 16-colors are part of the default configuration settings, it's reasonable to count on the controls being present. Actually, in the copy with ncurses 5.7, xterm-256color and screen-256color both have the same setaf/setab caps (inherited from xterm+256color). Debian must be on an older revision or have a local change. older... -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpT5xsS1Jz34.pgp Description: PGP signature
Bug#550701: tmux does not support screen-256color like it claims
On Sat, Oct 24, 2009 at 03:54:57PM -0400, Thomas Dickey wrote: On Sat, Oct 24, 2009 at 07:20:28PM +0200, Nicholas Marriott wrote: On Sat, Oct 24, 2009 at 12:49:31AM +1100, Tim Allen wrote: On Fri, Oct 23, 2009 at 01:24:00PM +0100, Nicholas Marriott wrote: It appears screen-256color converts colours 8-15 into 90-97 which are an extension designed to allow bright colours without the bold attribute (bold font). Looking at xterm's ctlseqs.pdf, it refers to these 90-97 and 100-107 codes as aixterm codes; I suppose before xterm invented the 88- and 256-color hack, IBM had their own ideas about how to extend ECMA48 beyond 8 colours. Yes, I know, but the question is why does terminfo bother itself converting 8-15 to 90-97 when it could just pass it through and get the same result since 90-97 are the same as 8-15 in the 256-colour palette. setaf/setab used to use the standard ANSI SGR sequence in xterm- and screen-256color, the change to use the 256-colour extension is relatively recent. as noted in terminfo.src # 2006-06-24 ... # * improve xterm-256color by combining the ibm+16color setaf/setab # strings with SGR 48. The setf/setb strings also are cancelled here # rather than omitted so derived entries will cancel those also -Alain # Bench The improvement reduces the number of characters sent. Ah yes, of course, I missed that. Colors 8-15 use the aixterm SGR (which isn't ANSI SGR). Right. Since aixterm 16-colors are part of the default configuration settings, it's reasonable to count on the controls being present. I can't count on them being present because tmux may be detached from a terminal which supports them and reattached to a terminal which does not, so unless I can establish for sure from terminfo that they are I have to assume they are not supported and convert them to bold+setaf/setab 0-7. With latest terminfo I could say that any terminal with colors=256 has a setaf/setab that correctly accepts all 256 colours, then use setaf/setab instead of sending \\033[38;5;c directly to get the benefit of any optimisations in terminfo, but that isn't a safe assumption with an older terminfo.src :-/. I suppose I could send the aixterm codes myself on 256 colour terminals but I'm not quite sure it is worth the effort. Plus 256 colours, default colours and mouse on/off are the only things for which tmux bypasses terminfo and I'd rather not add more. Actually I should use op to drop sending 39,49 directly as well. Actually, in the copy with ncurses 5.7, xterm-256color and screen-256color both have the same setaf/setab caps (inherited from xterm+256color). Debian must be on an older revision or have a local change. older... -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550701: tmux does not support screen-256color like it claims
On Sat, Oct 24, 2009 at 10:11:30PM +0100, Nicholas Marriott wrote: On Sat, Oct 24, 2009 at 03:54:57PM -0400, Thomas Dickey wrote: Since aixterm 16-colors are part of the default configuration settings, it's reasonable to count on the controls being present. I can't count on them being present because tmux may be detached from a terminal which supports them and reattached to a terminal which does not, so unless I can establish for sure from terminfo that they are I have to assume they are not supported and convert them to bold+setaf/setab 0-7. well... if you're using terminfo to tell the number of colors (256 for example), it's a reasonably safe assumption that xterm supports both the aixterm (16-color) and 256-color controls. Unless of course the $TERM is set incorrectly, in which case the 256-colors is suspect. For other terminals, the 16-color feature was used - which accounts for the 16color variants. With latest terminfo I could say that any terminal with colors=256 has a setaf/setab that correctly accepts all 256 colours, then use setaf/setab instead of sending \\033[38;5;c directly to get the benefit of any optimisations in terminfo, but that isn't a safe assumption with an older terminfo.src :-/. I'm not sure why - from what I'm reading the only problem was that tmux didn't recognize the aixterm codes. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgp6d5taVKtCG.pgp Description: PGP signature
Bug#550701: tmux does not support screen-256color like it claims
On Sat, Oct 24, 2009 at 07:42:26PM -0400, Thomas Dickey wrote: On Sat, Oct 24, 2009 at 10:11:30PM +0100, Nicholas Marriott wrote: On Sat, Oct 24, 2009 at 03:54:57PM -0400, Thomas Dickey wrote: Since aixterm 16-colors are part of the default configuration settings, it's reasonable to count on the controls being present. I can't count on them being present because tmux may be detached from a terminal which supports them and reattached to a terminal which does not, so unless I can establish for sure from terminfo that they are I have to assume they are not supported and convert them to bold+setaf/setab 0-7. well... if you're using terminfo to tell the number of colors (256 for example), it's a reasonably safe assumption that xterm supports both the aixterm (16-color) and 256-color controls. Unless of course the $TERM is set incorrectly, in which case the 256-colors is suspect. For other terminals, the 16-color feature was used - which accounts for the 16color variants. Yes, I can make that assumption but I'd have to bypass terminfo and output the 9x and 10x codes directly and I'm reluctant to add another case where I do that. I suppose it wouldn't do any harm, maybe I'll give it a go. With latest terminfo I could say that any terminal with colors=256 has a setaf/setab that correctly accepts all 256 colours, then use setaf/setab instead of sending \\033[38;5;c directly to get the benefit of any optimisations in terminfo, but that isn't a safe assumption with an older terminfo.src :-/. I'm not sure why - from what I'm reading the only problem was that tmux didn't recognize the aixterm codes. Yes, that problem is fixed, but I was thinking it would be nice to get the optimisation automatically using setaf/setab. Unfortunately, until very recently OpenBSD did this: $ TERM=xterm-256color tput setaf 10|cat -v; echo ^[[310m I thought it was fixed by using a newer terminfo.src (sorry) but checking again it is actually fixed by a separate OpenBSD bug fix just a few weeks ago. Anyway because of this tmux bypasses terminfo and just sends \\033[38;5;c directly and I am stuck with that at least until my fix gets into a couple of releases (or I #ifdef __OpenBSD__ it in tmux). On that note (I was actually going to mail you separately about this), there is a minor comment fix in OpenBSD that it would be nice if you could apply to your terminfo.src to make one fewer local change, a diff below. Thanks --- terminfo.src.orig Sun Oct 25 01:11:52 2009 +++ terminfo.srcSun Oct 25 01:13:22 2009 @@ -19562,7 +19562,7 @@ # # CTRM terminal emulator -# 1. underlining is not allowed with colors: first, is is simulated by +# 1. underlining is not allowed with colors: first, it is simulated by # black on white, second, it disables background color manipulations. # 2. BLINKING, REVERSE and BOLD are allowed with colors, # so we have to save their status in the static registers A, B and H -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550701: tmux does not support screen-256color like it claims
Hi If you set TERM to anything aside from screen or screen-256color inside tmux you will get screen corruption because applications will send the incorrect escape sequences. This is not a bug. The FAQ does not say that setting TERM to screen-256color will just work, although it could probably be clearer. You need to do two things: 1) Set TERM=screen-256color inside so that applications INSIDE tmux know that it supports 256 colours, you can do this however you like but default-terminal is usually easiest. 2) Ensure that tmux knows the outside terminal support 256 colours, either by setting TERM to something with colors=256, or matching *256col*, or by passing -2 to tmux. If you do not do this, tmux will translate ALL colours in the 256 colour palette into their nearest eight-colour equivalent. If you do step (2) and can successfully see 256 colours with, for example, the colortest script at http://www.vim.org/scripts/script.php?script_id=1349, and get them by using TERM=xterm-256color, then it sounds like a problem with the screen-256color terminfo entry. In this case, please send me a copy of infocmp screen-256color and tmux info. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550701: tmux does not support screen-256color like it claims
Hi
Okay, I can see the problem.
$ TERM=screen-256color tput setaf 15|cat -v
^[[97m
$ TERM=xterm-256color tput setaf 15|cat -v
^[[38;5;15
It appears screen-256color converts colours 8-15 into 90-97 which are an
extension designed to allow bright colours without the bold attribute (bold
font).
Looking briefly at xterm-256color in terminfo.src I can't see why it doesn't do
the same but I don't have time or inclination to dig into it right now.
I'm not certain why it does this because in 256 colour mode, colours 8-15 are
supposed to be the bright ANSI colours anyway, compare:
$ echo -e \\033[93mabc\\033[38\;5\;11mdef\\033[33m\\033[1mxyz
This appears to be yet another terminal capability without a terminfo flag
allowing it to be detected so tmux can't make use of it explicitly (ie pass it
through if it is supported). However, converting it into colours 8-15 (which
should then be converted into 3x+bold for non-256-colour terminals) should
hopefully do the trick.
Please try this:
Index: input.c
===
RCS file: /cvsroot/tmux/tmux/input.c,v
retrieving revision 1.97
diff -u -p -r1.97 input.c
--- input.c 15 Oct 2009 01:53:48 - 1.97
+++ input.c 23 Oct 2009 12:17:55 -
@@ -1494,6 +1494,28 @@ input_handle_sequence_sgr(struct input_c
gc-flags = ~GRID_FLAG_BG256;
gc-bg = 8;
break;
+ case 90:
+ case 91:
+ case 92:
+ case 93:
+ case 94:
+ case 95:
+ case 96:
+ case 97:
+ gc-flags |= GRID_FLAG_FG256;
+ gc-fg = m - 82;
+ break;
+ case 100:
+ case 101:
+ case 102:
+ case 103:
+ case 104:
+ case 105:
+ case 106:
+ case 107:
+ gc-flags |= GRID_FLAG_BG256;
+ gc-bg = m - 92;
+ break;
}
}
}
On Fri, Oct 23, 2009 at 10:30:34PM +1100, Tim Allen wrote:
On Fri, Oct 23, 2009 at 11:11:18AM +0100, Nicholas Marriott wrote:
The FAQ does not say that setting TERM to screen-256color will just
work, although it could probably be clearer. You need to do two
things:
My apologies - I already have 256-color support with appropriate TERM
settings working in gnome-terminal and screen, so from my point of view,
setting TERM inside tmux was the only thing I believed missing.
If you do step (2) and can successfully see 256 colours with, for
example, the colortest script at
http://www.vim.org/scripts/script.php?script_id=1349, and get them by
using TERM=xterm-256color, then it sounds like a problem with the
screen-256color terminfo entry. In this case, please send me a copy of
infocmp screen-256color and tmux info.
I have attached the output of infocmp screen-256color and tmux info
as you requested.
The colortest script that you link to is useful but verbose - I have
written my own color-test script (also attached) whose output is more
compact, and also attached a screenshot comparing the output with
TERM=screen-256color versus the output with TERM=xterm-256color. It
seems that the 256 colours are represented well enough, it's the colours
from 8-15 that aren't being interpreted correctly.
# Reconstructed via infocmp from file: /lib/terminfo/s/screen-256color
screen-256color|GNU Screen with 256 colors,
am, km, mir, msgr, xenl,
colors#256, cols#80, it#8, lines#24, ncv#3, pairs#32767,
acsc=++\,\,--..00``aaffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[?25l,
clear=\E[H\E[J, cnorm=\E[34h\E[?25h, cr=^M,
csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\EM,
cvvis=\E[34l, dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM,
dl1=\E[M, ed=\E[J, el=\E[K, el1=\E[1K, enacs=\E(B\E)0,
flash=\Eg, home=\E[H, ht=^I, hts=\EH, ich=\E[%p1%d@,
il=\E[%p1%dL, il1=\E[L, ind=^J, initc@, is2=\E)0, kbs=^H,
kcbt=\E[Z, kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA,
kdch1=\E[3~, kend=\E[4~, kf1=\EOP, kf10=\E[21~,
kf11=\E[23~, kf12=\E[24~, kf2=\EOQ, kf3=\EOR, kf4=\EOS,
kf5=\E[15~, kf6=\E[17~, kf7=\E[18~, kf8=\E[19~, kf9=\E[20~,
khome=\E[1~, kich1=\E[2~, kmous=\E[M, knp=\E[6~, kpp=\E[5~,
nel=\EE, op=\E[39;49m, rc=\E8, rev=\E[7m, ri=\EM, rmacs=^O,
rmcup=\E[?1049l, rmir=\E[4l, rmkx=\E[?1l\E, rmso=\E[23m,
rmul=\E[24m, rs2=\Ec\E[?1000l\E[?25h, sc=\E7,
setab=\E[%?%p1%{8}%%t4%p1%d%e%p1%{16}%%t10%p1%{8}%-%d%e48;5;%p1%d%;m,
setaf=\E[%?%p1%{8}%%t3%p1%d%e%p1%{16}%%t9%p1%{8}%-%d%e38;5;%p1%d%;m,
Bug#550701: tmux does not support screen-256color like it claims
On Fri, Oct 23, 2009 at 01:24:00PM +0100, Nicholas Marriott wrote: It appears screen-256color converts colours 8-15 into 90-97 which are an extension designed to allow bright colours without the bold attribute (bold font). Looking at xterm's ctlseqs.pdf, it refers to these 90-97 and 100-107 codes as aixterm codes; I suppose before xterm invented the 88- and 256-color hack, IBM had their own ideas about how to extend ECMA48 beyond 8 colours. Looking briefly at xterm-256color in terminfo.src I can't see why it doesn't do the same but I don't have time or inclination to dig into it right now. There's a family of screen terminfo entries, and a family of xterm terminfo entries; if screen-256color inherits from screen-16color but xterm-256color overrides setab and setaf entirely, that might explain it. I'm not sure how to go about checking that, though, and as you say, it hardly matters. This appears to be yet another terminal capability without a terminfo flag allowing it to be detected so tmux can't make use of it explicitly (ie pass it through if it is supported). However, converting it into colours 8-15 (which should then be converted into 3x+bold for non-256-colour terminals) should hopefully do the trick. I applied your patch to the Debian source, rebuilt the package and installed it, and my color-test script works fine now as does my mutt configuration. Thank you very much! Tim. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550701: tmux does not support screen-256color like it claims
On Sat, Oct 24, 2009 at 12:49:31AM +1100, Tim Allen wrote: On Fri, Oct 23, 2009 at 01:24:00PM +0100, Nicholas Marriott wrote: It appears screen-256color converts colours 8-15 into 90-97 which are an extension designed to allow bright colours without the bold attribute (bold font). Looking at xterm's ctlseqs.pdf, it refers to these 90-97 and 100-107 codes as aixterm codes; I suppose before xterm invented the 88- and 256-color hack, IBM had their own ideas about how to extend ECMA48 beyond 8 colours. Yes, I know, but the question is why does terminfo bother itself converting 8-15 to 90-97 when it could just pass it through and get the same result since 90-97 are the same as 8-15 in the 256-colour palette. setaf/setab used to use the standard ANSI SGR sequence in xterm- and screen-256color, the change to use the 256-colour extension is relatively recent. Looking briefly at xterm-256color in terminfo.src I can't see why it doesn't do the same but I don't have time or inclination to dig into it right now. There's a family of screen terminfo entries, and a family of xterm terminfo entries; if screen-256color inherits from screen-16color but xterm-256color overrides setab and setaf entirely, that might explain it. I'm not sure how to go about checking that, though, and as you say, Actually, in the copy with ncurses 5.7, xterm-256color and screen-256color both have the same setaf/setab caps (inherited from xterm+256color). Debian must be on an older revision or have a local change. This appears to be yet another terminal capability without a terminfo flag allowing it to be detected so tmux can't make use of it explicitly (ie pass it through if it is supported). However, converting it into colours 8-15 (which should then be converted into 3x+bold for non-256-colour terminals) should hopefully do the trick. I applied your patch to the Debian source, rebuilt the package and installed it, and my color-test script works fine now as does my mutt configuration. Thank you very much! Okay cool, I will commit it. Thanks for the report. Regards Nicholas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550701: tmux does not support screen-256color like it claims
Package: tmux Version: 1.0-1 Severity: normal In /usr/share/doc/tmux/FAQ.gz, it is suggested that to get 256 color terminal support all one needs to do is to set the default $TERM to screen-256color and everything will Just Work; it seems this is not actually the case. Inside GNU screen, running the following command: TERM=screen-256color tput setaf 10; echo hello ...yields the text hello in lime green. Inside tmux, the same command yields the text hello in the default terminal foreground color. Meanwhile, the following command *does* work as expected inside tmux: TERM=xterm-256color tput setaf 10; echo hello ...but leaving TERM set to xterm-256color seems to have unfortunate screen-corruption side-effects with mutt, so it's not really a useful workaround. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-686 (SMP w/1 CPU core) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages tmux depends on: ii libc6 2.9-25 GNU C Library: Shared libraries ii libncurses5 5.7+20090803-2 shared libraries for terminal hand tmux recommends no packages. tmux suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550701: tmux does not support screen-256color like it claims
Hi, thanks for your report. Am Montag 12 Oktober 2009 12:46:03 schrieb Screwtape: Package: tmux Version: 1.0-1 Severity: normal In /usr/share/doc/tmux/FAQ.gz, it is suggested that to get 256 color terminal support all one needs to do is to set the default $TERM to screen-256color and everything will Just Work; it seems this is not actually the case. Inside GNU screen, running the following command: TERM=screen-256color tput setaf 10; echo hello ...yields the text hello in lime green. Inside tmux, the same command yields the text hello in the default terminal foreground color. Meanwhile, the following command *does* work as expected inside tmux: TERM=xterm-256color tput setaf 10; echo hello ...but leaving TERM set to xterm-256color seems to have unfortunate screen-corruption side-effects with mutt, so it's not really a useful workaround. I could reproduce this behaviour but not the issue with mutt. Could you give more detail on mutt's screen-corruption? Regards, Ferdinand -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-686 (SMP w/1 CPU core) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages tmux depends on: ii libc6 2.9-25 GNU C Library: Shared libraries ii libncurses5 5.7+20090803-2 shared libraries for terminal hand tmux recommends no packages. tmux suggests no packages. -- no debconf information signature.asc Description: This is a digitally signed message part.
Bug#550701: tmux does not support screen-256color like it claims
On Mon, Oct 12, 2009 at 01:14:49PM +0200, Karl Ferdinand Ebert wrote: I could reproduce this behaviour but not the issue with mutt. Could you give more detail on mutt's screen-corruption? My problem was that with TERM=xterm-256color inside tmux, mutt would draw rows at the wrong place as you scrolled through the message list. However, I first observed this behaviour with tmux 0.8; it doesn't seem to be a problem with 1.0. tmux isn't quite compatible with TERM=xterm-256color, though. xterm implements 'background color erase', which means that the following command paints the entire terminal green: tput setab 2; tput clear tmux doesn't support 'background color erase', which means that the above command results in a terminal in the default colours. This shows up in mutt in the very first line, where keyboard shortcuts are displayed - if this line has a background colour, and TERM=xterm-256color (or any color xterm variant) the background colour extends all the way across the window in screen and gnome-terminal, while in tmux the background-color stops at the right-most text on the line. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
