What exactly is in your prompt? Either send it through cat -v or run script and hit enter a few times then send me the script file.
It is clearly your prompt that is causing tmux to leave bright turned on until the SGR 27 you send causes it to reset. I bet clearing any attribute will do it, not just reverse, because they will all trigger an SGR 0. On Fri, Oct 28, 2011 at 06:56:32PM +0200, Natacha Port? wrote: > Hello, > > on Friday 28 October 2011 at 16:56, Nicholas Marriott wrote: > > I don't really follow what your problem is, and you must be using > > terminfo or tmux wouldn't work (it can't use termcap). > > Well I know for a fact that FreeBSD doesn't have terminfo support. > However accroding to ldd, tmux is linked with libncurses from FreeBSD > base; maybe libncurses exposes a terminfo interface, however the > underlying database (that which I can configure as root) is clearly > termcap. > > > What exactly do you have in your prompt? Do echo $PS1|cat -v > > It's quite complicated and I don't think it's actually needed, so let's > focus on the bottommost part of each window from my screenshot. > > My rxvt-unicode is configured to use #002b36 as default background color > and #839496 as default foreground color. > > The first part is the text "normal" in #657b83 on #002b35, which are > respectively colors 11 and 8. This is not consistent with the default > colors from rxvt-unicode, but my prompt does mess up with colors, so > let's assume it's fine. > > Then there is a resverse-video escape sequence \033[7m, followed by the > text "avec reverse", which is displayed in #002b35 on #657b63 (8 on 11), > which is consistent with the previous state. > > Then reverse-video is ended with \003[27m, followed by the text > "sans reverse (re-normal ?)", which is displayed in #657b83 on #002b35 > (11 on 8), so back to the state before enabling reverse-video, as > intended. > > Then there is a sgr0 escape sequence \033[m, followed by the text "apr?s > reset" (first occurrence), which is still #657b83 on #002b35 (11 on 8), > so this is presumably the default cell state, so far so good. > > Then escape sequence \033[36m sets foreground color to 6 (which is > #2aa198), and the following text "en cyan" is indeed in #2aa198 on > #002b35 (6 on 8), so everything is still fine. > > Then there is sgr0 escape sequence \033[m, and the following text "apr?s > reset" is in #eee8d5 on #002b36 (7 on 8). > > So what suspiciously looks like a bug is that in that particular line, > the first text after sgr0 is displayed in #657b83 on #002b35 (11 on 8) > while the second time, after sgr0 text is in #eee8d5 on #002b36 (7 on > 8). The source code however lets believe that foreground and background > colors are wiped by sgr0 escape sequence. So how can that be?? > > > > Now the second symptom of what I guess is the same problem is shown in > the first line of the tmux window: > text starts already in "atlered" mode, #eee8d5 on #002b36 (7 on 8). > > Then escape sequence for reverse-video \033[7m, "avec reverse" is in > #002b36 on #eee8d5 (8 on 7), exactly as expected from the previous > state. > > Then escape sequence to stop reverse-video \033[27m, and the following > text is in #657b83 on #002b35 (11 on 8). That means that \033[27m did > not exactly cancel the action of \033[7m, something else happened to get > the display out of the "altered" mode. > > > > So the bottom line from the screen shot is that there is somewhere a > sort of persistent state that is not changed by sgr0, which is changed > when requesting a particular foreground color and which is reverted when > going out of a special font mode (italics, reverse-video, alternate > character set, etc). > > And of course, the bare rxvt-unicode window is there as a control, to > show that this effect happens only in tmux, despite having exactly the > same shell prompt and the same escape sequences for these particular > entries. > > > Is the problem clearer now, or should I try to build a clearer > screenshot?? > > > > I should probably also add that the problem is not really only about > shell prompts and escape sequences, it's just that I was trying to > isolate the smallest test case exhibiting the issue. I would like to see > it solved because it has a much broader impact than that, see for > example?: > http://instinctive.eu/screenshots/20111026-143434-tmux-bug-irssi.png > where the last line (IRC prompt) suddenly switches from #eee89d5 on > #073642 (color 7 on 0) to #657b83 on #002b36 (color 11 on 8), but irssi > is using ncurses, and the color change is not related to the text > contents but to text movement, I have no idea how to dig into that. > Similarly, > http://instinctive.eu/screenshots/20111028-184514-tmux-bug-mutt.png > text above the highlighted line is in #586e75 on #002b36 (color 10 on > 8), as is the text below the first blue line?; however between the > yellow line and the blue line, text is in #586e75 on #073642 (color 10 > on 0). This is again an application using ncurses, and it is triggered > when the cursor is moved upwards, the line that used to be highlighted > in yellow turns into 10 on 0, while when the cursor is moved downwards, > the previously highlighted line is turned into the correct 10 on 8. But > again, I have no idea how to investigate that. > > And of course, both application don't exhibit any color inconsistency in > rxvt-unicode without tmux (with exactly the same configuration). > > > Thanks in advance for your help, > Natacha Port? > ------------------------------------------------------------------------------ Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev _______________________________________________ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
