tmux -CC : first window theme different from the subsequent ones

Required information for bugs. I probably can't help you unless you include this:

• iTerm2 version
• OS version
• Attach com.googlecode.iterm2.plistcom.googlecode.iterm2.plist here
• Attach a debug log (https://iterm2.com/debuglog) Hi,

Working on MBP under El Capitan (10.11.4), with iTerm2 Build 2.9.20160426 and tmux 2.1.

I'm trying to use tmux -CC but get the following strange behaviour (see attached screenshot) :

1 - when doing tmux -CC new-session, the window (tab really, but I've then exploded those into windows for the screeshot) that appears is white (while my theme is a dark one). Note that this one is numbered 3 in the screenshot (no idea why ?)

2 - the next windows (or tabs) (numbered 1 and 4) appear to have the correct theme but littered with a bunch of "tmux;tmux;..." (29 to be precise).

Concerning the point 2 I guess this is related to the theming script I use (https://github.com/chriskempson/base16-shell/blob/master/base16-solarized.dark.sh) which indeeds sends "strange" things in the tmux case (that's something to be sorted out for sure). But what I don't get is why the first window is different ?

Thanks,

mentioned in issue #4592 (closed)

The only way I can think of this happening is if something sends the escape sequence to change colors or profiles. Could you provide a debug log? Instructions are at https://iterm2.com/debuglog. If you don't want to attach it here you can email it to gnachman at gmail.com, and please put the bug number in the subject line.

Your second point looks like something is sending the tmux "wrapper" sequence to pass an escape code through to iTerm2 but it's not working right (such sequences begin with escPtmux;).

Your second issue is a dup of #4592 (closed) and is fixed in the nightly build.

Thanks for looking into this. Here's the debug log.

debuglog.txt

The colors are changing because something is sending this escape sequence: esc]4;1;rgb:dc/32/2fbell (and many others, they're changing all colors from index 1 to index 21). Check your .bashrc and friends to find the culprit. Could be base16-solarized.dark.sh that's doing it.

Yes, the solarized script is changing the colors, that's expected I would say. What is not is why the first window doesn't have its colors changed, while the next ones have...

BTW, concerning the second point I tried the nightly build (Build 2.9.20160503-nightly) and yes, the spurious "tmux;tmux;..." are gone, but I have to hit enter twice in the window to get my prompt...

Can you tell if the solarized script is running in the first window? Add something like echo "hello world" to the top of the solarized script and see if it appears. I modified my .login file to load the solarized script and all my windows changed colors.

Yes, the solarized script is executed in both cases

A few bugs:

1. We were only parsing one DCS code per read, which is why you had to bang on the keyboard to get a prompt. Fixed in ae42e3f0.
2. The solarized script has a bug where it emits BEL characters to terminate OSC P codes but only when in tmux. This makes iTerm2 beep. This is the one OSC code that is fixed length.
3. There's a race condition when your login script writes an escape sequence that sets the color. The input gets processed before the window is created, which means its color-change code is stomped on when the profile is set on the session. That's why sometimes a window will get the colors and sometimes it won't. This is tricky to solve. I'm leaving this issue open to work on this part of it.

More detail on the remaining issue:

We ignore output we read before the initial command list finishes completing. This prevents duplicate output (e.g., your login script writes "hello world" and we fetch history, which includes "hello world", so we mustn't process that output).

The problem arises when the input contains escape sequences that modify the profile's attributes that aren't its actual text (color is all that comes to mind at the moment, but there are probably other things too).

The "real" solution is for tmux to track colors so we can get the canonical palette from tmux. There's something to be said for this approach:

1. Many terminals understand the codes to change colors, so "traditional" tmux would benefit from this as much as us
2. The hack you're using doesn't restore the colors when doing tmux -CC attach

The main down side I see is that the OSC code in question is screwy and tmux's parser would need to be contorted pretty horribly to consume it properly. It's worth a try, but I'm going to punt this til 3.1 since it is a nontrivial amount of effort.

Note to self: the issue with ignoring input is that acceptNotifications_ in TmuxGateway is set to NO until this code runs:

    if ([[currentCommand_ objectForKey:kCommandIsInitial] boolValue]) {
        acceptNotifications_ = YES;
    }

and that causes %output notifications to get dropped.

Milestone changed to Feature Complete 3.1

mentioned in issue #4616 (closed)

Milestone changed to Feature Complete 3.2