Tmux status line fills up the buffer

[zadjii-msft]

Filed re: discussion on https://www.reddit.com/r/bashonubuntuonwindows/comments/8j6xbt/vim_tmux_on_wsl/

sam007961

It sort of works. The tmux theme is buggy and unusable, but everything else works fine.
The thing is I'm not sure if the source of the bug is tmux or the default terminal or even the theme. The major issue was was the tmux status line would keep reprinting and eventually filling up the screen when the theme is enabled. I read somewhere that this is an issue related to Unicode character width. It could also be some kind of Unicode mismatch between tmux and the default terminal.
I was able to fix the buggy status line somehow by configuring both bash and tmux to 256 color mode. Not sure why or how that fixed it, but some colors are still off in tmux. My guess is it might have to do with bold fonts. (i.e cmd interprets bold as a color)

zadjii

The major issue was was the tmux status line would keep reprinting and eventually filling up the screen when the theme is enabled

Oooh, that might actually be a real bug. I think I've noticed that with my own tmux instance - I assumed it was a bug with the interop work I was doing, but that's clearly not the case if it's reproing for you on Fall Creator's Update. I probably regressed something here.

I was able to fix the buggy status line somehow by configuring both bash and tmux to 256 color mode.

... That's certainly interesting. That almost raises more questions, but might be helpful in figuring it out.

My guess is it might have to do with bold fonts. (i.e cmd interprets bold as a color)

Right on - conhost doesn't support bolded fonts, so we only bold the color (which is pretty typical behavior). There is still some outstanding bugginess with 256 color and bolding, so that should get better in April Update.

[BarrettStephen]

I just installed windows terminal and hoped this issue would be fixed since its a new tech stack, but the issue remains. Any chance someone can look at this?

Its one of a few text formatting bugs I've noticed with windows terminal which prevent me from using it

[BarrettStephen]

You can reproduce this issue with this minimal .tmux.conf:

# ----------------------
# Status Bar
# -----------------------
set-option -g status on                # turn the status bar on
set -g status-interval 5               # set update frequencey (default 15 seconds)

set-window-option -g window-status-current-attr bright

# show session name, window & pane number, date and time on right side of
# status bar
set -g status-right-length 60
set -g status-right "#[fg=blue]#S #I:#P #[fg=yellow]:: %d %b %Y #[fg=green]:: %l:%M %p :: #(date -u | awk '{print $4}')::"

[BarrettStephen]

Turns out I had "export TERM=screen-256color" in my .bashrc.
When I removed that, everything worked. The default was "xterm-256color"

[tkonya]

I am experiencing the issue listed here, under Troubleshooting > Status line is broken and/or gets duplicated at the bottom of the screen. What gives?

This particularly happens on Linux when the distribution provides a version of glib that received Unicode 9.0 upgrades (glib >= 2.50.1) while providing a version of glibc that didn't (glibc < 2.26). You may also configure LC_CTYPE to use an UTF-8 locale. Typically VTE based terminal emulators rely on glib's g_unichar_iswide() function while tmux relies on glibc's wcwidth() function. When these two functions disagree, display gets messed up.

This can also happen on macOS when using iTerm2 and "Use Unicode version 9 character widths" is enabled in Preferences... > Profiles > Text

For that reason, the default ~/.tmux.conf.local file stopped using Unicode characters for which width changed in between Unicode 8.0 and 9.0 standards, as well as Emojis.

This happens when I ssh into a box with tmux installed. I have not been able to resolve it. It seems to happen with both WSL1 and WSL3 (with Ubuntu from the Microsoft Store). Things get especially screwy when I try to type, because there is a mismatch between where it looks like the cursor is / where it should be and where what I type is being printed.

When I first connect, everything seems normal. Every time the tmux status line updates, it actually pushes everything up one row, duplicating itself. If no commands are input then this will happen until the screen is completely filled. Some things, such as entering vim, will clear the screen, but the process will just start over as long as the tmux status line is present and updating.

Notice in the image above where "ls" is printed - inside of the duplicated status line. I have redacted some parts of this image in orange. It gets even weirder when using vim; characters are printed all over the place. It's totally unusable.

Note: this does not happen when using MobaXTerm, so I am assuming that the problem is not with WSL, but with this, the terminal.

[fergalmoran]

Turns out I had "export TERM=screen-256color" in my .bashrc.
When I removed that, everything worked. The default was "xterm-256color"

I get this even with xterm-256color both over ssh and WSL2 - it's preventing me from using WT as my daily terminal.

[fergalmoran]

Hi - sorry for the noise but @shanselman asked me via email to ping this issue.

Here is a minimal tmux.conf repro.

	set-option -g status on
	set -g status-interval 5
	
	set-window-option -g window-status-current-attr bright
	
	set -g status-right-length 60
	set -g status-right "#[fg=blue]#S #I:#P #[fg=yellow]:: %d %b %Y #[fg=green]:: %l:%M %p :: #(date -u | awk '{print $4}')::"

And here is a screenshot of tmux running in the terminal using WSL2 (same issue over an SSH connection to and number of Linux hosts.

[DHowett-MSFT]

@shanselman knows how we handle bugs in this repository.

[DHowett-MSFT]

I really wish I could repro it, but I'm not getting anything out of the ordinary with that config.. even if I give my shell a righthand prompt.

[DHowett-MSFT]

[shanselman]

@DHowett-MSFT sorry, I'd asked for a Bug Report ;)

[fergalmoran]

Apologies if I've done something wrong, @shanselman you did ask me for a bug report, I pointed out there was already an open one, you told me "Maybe ping it and add your screenshots." which I did. I'm happy to open another issue but this one describes the problem perfectly? I'm also happy to give remote access to my PC if this helps anyone?

[DHowett-MSFT]

Oh, you haven't done anything wrong 😄 sorry about being crabby. Everything you've done is great.

I just can't reproduce it!

[BarrettStephen]

Did you set TERM per my comment higher up?

[DHowett-MSFT]

If I set TERM to something that isn't the terminal that we are, I can reproduce it. @fergalmoran suggests that they can reproduce it even with TERM set to xterm-256color.

Incidentally, setting TERM to screen-256color also recapitulates the weird white boxes @fergalmoran is seeing . . .

Fergal, can you confirm TERM directly before launching tmux?

[fergalmoran]

Yes - TERM is set as per @BarrettStephen 's comment

And this is TERM within a tmux session - apologies for the artifacts.... but y'know... this bug!! :)

[DHowett-MSFT]

Curious.
Would you mind sharing the output of infocmp (outside of tmux)?

[fergalmoran]

No problem..

infocmp
#       Reconstructed via infocmp from file: /lib/terminfo/x/xterm-256color
xterm-256color|xterm with 256 colors,
        am, bce, ccc, km, mc5i, mir, msgr, npc, xenl,
        colors#0x100, cols#80, it#8, lines#24, pairs#0x10000,
        acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
        bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[?25l,
        clear=\E[H\E[2J, cnorm=\E[?12l\E[?25h, cr=\r,
        csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
        cud=\E[%p1%dB, cud1=\n, cuf=\E[%p1%dC, cuf1=\E[C,
        cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
        cvvis=\E[?12;25h, dch=\E[%p1%dP, dch1=\E[P, dim=\E[2m,
        dl=\E[%p1%dM, dl1=\E[M, ech=\E[%p1%dX, ed=\E[J, el=\E[K,
        el1=\E[1K, flash=\E[?5h$<100/>\E[?5l, home=\E[H,
        hpa=\E[%i%p1%dG, ht=^I, hts=\EH, ich=\E[%p1%d@,
        il=\E[%p1%dL, il1=\E[L, ind=\n, indn=\E[%p1%dS,
        initc=\E]4;%p1%d;rgb\:%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\E\\,
        invis=\E[8m, is2=\E[!p\E[?3;4l\E[4l\E>, kDC=\E[3;2~,
        kEND=\E[1;2F, kHOM=\E[1;2H, kIC=\E[2;2~, kLFT=\E[1;2D,
        kNXT=\E[6;2~, kPRV=\E[5;2~, kRIT=\E[1;2C, kb2=\EOE, kbs=^?,
        kcbt=\E[Z, kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA,
        kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\EOP, kf10=\E[21~,
        kf11=\E[23~, kf12=\E[24~, kf13=\E[1;2P, kf14=\E[1;2Q,
        kf15=\E[1;2R, kf16=\E[1;2S, kf17=\E[15;2~, kf18=\E[17;2~,
        kf19=\E[18;2~, kf2=\EOQ, kf20=\E[19;2~, kf21=\E[20;2~,
        kf22=\E[21;2~, kf23=\E[23;2~, kf24=\E[24;2~,
        kf25=\E[1;5P, kf26=\E[1;5Q, kf27=\E[1;5R, kf28=\E[1;5S,
        kf29=\E[15;5~, kf3=\EOR, kf30=\E[17;5~, kf31=\E[18;5~,
        kf32=\E[19;5~, kf33=\E[20;5~, kf34=\E[21;5~,
        kf35=\E[23;5~, kf36=\E[24;5~, kf37=\E[1;6P, kf38=\E[1;6Q,
        kf39=\E[1;6R, kf4=\EOS, kf40=\E[1;6S, kf41=\E[15;6~,
        kf42=\E[17;6~, kf43=\E[18;6~, kf44=\E[19;6~,
        kf45=\E[20;6~, kf46=\E[21;6~, kf47=\E[23;6~,
        kf48=\E[24;6~, kf49=\E[1;3P, kf5=\E[15~, kf50=\E[1;3Q,
        kf51=\E[1;3R, kf52=\E[1;3S, kf53=\E[15;3~, kf54=\E[17;3~,
        kf55=\E[18;3~, kf56=\E[19;3~, kf57=\E[20;3~,
        kf58=\E[21;3~, kf59=\E[23;3~, kf6=\E[17~, kf60=\E[24;3~,
        kf61=\E[1;4P, kf62=\E[1;4Q, kf63=\E[1;4R, kf7=\E[18~,
        kf8=\E[19~, kf9=\E[20~, khome=\EOH, kich1=\E[2~,
        kind=\E[1;2B, kmous=\E[M, knp=\E[6~, kpp=\E[5~,
        kri=\E[1;2A, mc0=\E[i, mc4=\E[4i, mc5=\E[5i, meml=\El,
        memu=\Em, oc=\E]104\007, op=\E[39;49m, rc=\E8,
        rep=%p1%c\E[%p2%{1}%-%db, rev=\E[7m, ri=\EM,
        rin=\E[%p1%dT, ritm=\E[23m, rmacs=\E(B, rmam=\E[?7l,
        rmcup=\E[?1049l\E[23;0;0t, rmir=\E[4l, rmkx=\E[?1l\E>,
        rmm=\E[?1034l, rmso=\E[27m, rmul=\E[24m,
        rs1=\Ec\E]104\007, rs2=\E[!p\E[?3;4l\E[4l\E>, 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,
        sgr=%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p5%t;2%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m,
        sgr0=\E(B\E[m, sitm=\E[3m, smacs=\E(0, smam=\E[?7h,
        smcup=\E[?1049h\E[22;0;0t, smir=\E[4h, smkx=\E[?1h\E=,
        smm=\E[?1034h, smso=\E[7m, smul=\E[4m, tbc=\E[3g,
        u6=\E[%i%d;%dR, u7=\E[6n, u8=\E[?%[;0123456789]c,
        u9=\E[c, vpa=\E[%i%p1%dd,

[DHowett-MSFT]

I was hoping for something more dramatic.

(DHOWETT-DEV2) /mnt/e % diff -u xterm-mine xterm-fergal; echo $?
0

[DHowett-MSFT]

I'm somewhat surprised TERM is xterm-256color inside tmux, actually. It calls this out in the manual:

 The TERM environment variable must be set to ‘screen’ or ‘tmux’ for all programs running inside tmux.
 New windows will automatically have ‘TERM=screen’ added to their environment, but care must be taken not
 to reset this in shell start-up files.

[fergalmoran]

Apologies for not being dramatic enough

I was setting TERM=xterm-256color in my .zshrc - I've removed that now and TERM is set to screen but the issue still persists?

Clearly I'm doing something wrong but at a loss. For what it's worth, tmux works perfectly using putty, mobaxterm or any number of terminals running natively on Linux with the same zsh & tmux settings. I only see this behaviour using Windows Terminal.

[DHowett-MSFT]

Could you copy/paste one of those unexpected squares into xxd or something else that'll read out what character code it is? I wonder if it's SI/SO (#3487). If that's the case, it would be throwing off our character column counts and causing accidental line wrapping.

[fergalmoran]

I think you're onto something.. (note the perfectly lovely tmux session on my home PC 😏 - also the late time here, so I'll pick this up tomorrow!)

[DHowett-MSFT]

YES. Okay, we have proximal cause. There's an open pull request that actually adds support for SI/SO and friends, but it's huge so we haven't yet had a chance to review it.

I know this bug's got a nice low number, but I'm going to close it as a /dupe of #3487. The other person who reported the same issue has the same boxes in their output.

[ghost]

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

[DHowett-MSFT]

Thanks so much for your help, @fergalmoran. And yes, thanks @shanselman for telling Fergal to refresh us on this issue 😄

[fergalmoran]

No problem at all and thank you for all your help here!! Absolutely love this terminal and use it all the time with Powershell - will be delighted to be able to use it with Linux!

[DHowett-MSFT]

@fergalmoran If you get a chance, could you share the output of locale (outside of tmux)? If locale doesn't exist, echo $LANG $LC_CTYPE $LC_ALL will suffice.

[fergalmoran]

@DHowett-MSFT - sure! (I'm in Ireland, hence the en_IE 😄 )

locale
LANG=en_IE.UTF-8
LANGUAGE=
LC_CTYPE="en_IE.UTF-8"
LC_NUMERIC="en_IE.UTF-8"
LC_TIME="en_IE.UTF-8"
LC_COLLATE="en_IE.UTF-8"
LC_MONETARY="en_IE.UTF-8"
LC_MESSAGES="en_IE.UTF-8"
LC_PAPER="en_IE.UTF-8"
LC_NAME="en_IE.UTF-8"
LC_ADDRESS="en_IE.UTF-8"
LC_TELEPHONE="en_IE.UTF-8"
LC_MEASUREMENT="en_IE.UTF-8"
LC_IDENTIFICATION="en_IE.UTF-8"
LC_ALL=

[DHowett-MSFT]

Thanks! I was hoping it would shed some light on why tmux thinks it has to use the alternative character set control codes (because if we can suppress that I can unblock you 😄)

[fergalmoran]

@DHowett-MSFT I'm going to build the PR tomorrow morning when I'm back at my Windows PC and see if it changes anything, I'll let you know how I get on. Hopefully that can shed some light.