Rendering errors in tmux split panes

[sw00]

Environment

Windows build number: Microsoft Windows [Version 10.0.19042.388]
Windows Terminal version (if applicable): 1.0.1811.0
tmux 3.0a
Alacritty 0.4.2

Steps to reproduce

Run tmux in Windows terminal WSL2 (Ubuntu), after a fresh boot into Windows.
Create some horizontal split panes in tmux (works)
Create some vertical split panes in tmux
Run some commands with output (in some panes)

Oddly, the symptom disappears if I close and start Windows terminal again and re-attach to tmux.

Expected behavior

Text output is clear and readable and output in their respective panes.

Actual behavior

The text output from different processes seems to bleed across panes.
This occurs with a vanilla/empty tmux config too.

My TERM is set to xterm-256color outside tmux and tmux-256color in tmux.

This behaviour also seems to happen in Alacritty (0.4.2), which in my understanding shares the same backend (ConPTY?) as Windows Terminal.

[sschlesier]

I have observed the same.

It worked well with the first official release and then broke in the first official update.

I installed a preview release in which it was working, but also recently broke with an update.

I was about to try and test all the recent releases to see where it does/does not work. I noticed an odd thing. If I launch WSL2 and get a tmux session running in an old working version of the official terminal, and then attach a broken version of the preview terminal to the same tmux session the display will remain correct in both terminals. However if I close both terminals and wsl -t to terminate the wsl session, and then launch wsl and tmux again with a broken terminal it will not render correctly. That surprised me and hopefully is a helpful clue.

For now I've run out of time to try and track this down.

[sschlesier]

Oh, I missed the close and start again comment. Maybe that is the factor that has made me think certain versions were fixed/broken and explains the render keeps working with both the preview and release versions.

[kianryan]

Observing identical problems with:
Windows Terminal Version: 1.1.2021.0
Tmux 3.0a
WSL 2 / Ubuntu 20.04
TERM=xterm-256color (outside)
TERM=tmux-256color (inside)

[zadjii-msft]

First - very sorry that this got lost in the triage queue.

Second - does this only repro in tmux 3.0a? Maybe they're using something new in 3.0 that we don't support quite yet? I'm sitting here on 18.04 with tmux 2.6 and I just can not repro this. Lemme pull a 20.04 and see if I can't get this to happen with an updated tmux.

[zadjii-msft]

Huh. I could not get this to repro with a fresh ubuntu 20.04 and tmux 3.0a, UNTIL I tried installing fish:

I'm not sure if it'll happen again, but I could repro this at least once, so there's something.

EDIT: tmux-256color is certainly a weird termcap:

[zadjii-msft]

Alright other findings here

• Once a Windows Terminal pane is corrupted by this, it will stay corrupted. With the pane that's busted for me, every time I try killing all my tmux sessions and opening a new one in that WT pane, it's got the same visual corruption as OP.
• The corruption seems to be caused by tmux or conpty causing the mouse to go back to the 1st column instead of where the pane separator should be. maybe there's a bug with calculating where the tab stops should be?
  • tmux is redrawing the contents of the bottom right pane correctly, but when I force a redraw of the entire window, then tmux will draw the corrupted rows starting from column 0, instead of the separator.
    

[zadjii-msft]

Alright last update:

This has definitely got something to do with line wrapping. My gut thinks that this is related to #6901/#7028/#7253, but I can't be sure, since I can't get a solid repro right now.

Take a look at this output copied from a broken tmux and a working one. They should both have the same contents in their panes:

Note that the first one has all copied as one single wrapped line.

I've also got the attached tracking of me opening tmux, making a [|] split, and running htop in it:
gh-6987-trace.txt

There's nothing terribly out of the ordinary there. I split the pane around L958, and start htop around 2215.

I'm gonna toss this on V2, and link it up with #5800. If anyone's got a way to more consistently repro this from a fresh WT window, that'd be much appreciated. Thanks all!

[zadjii-msft]

Ho boy this looks awfully a lot like

Tmux pane content gets garbled after refreshing tmux client #4029

[altjx]

Any updates on this? Having the exact same issue pretty consistently as well. Let me know if I can contribute to the troubleshooting process.

[llinfeng]

I am having a slightly different problem, where the status bar for tmux should grow "taller" by duplicating itself. It also inserts a line with b-21 or 21 at the bottom. Tmux shortcuts are not working as intended as well.

This is observed both on tmux sessions running in a local WSL instance, or tmux sessions hosted on remote Linux machines. The .tmux.config file for both tmux sessions are identical, as I source from the same Dropbox directory.

To note, all these problems go away should I stay with wsltty.

[DHowett]

@llinfeng there are so many different variables here. Are you using Windows Terminal or the original windows console? What version of Terminal? What version of Windows?

[llinfeng]

Short summary: what I was describing can be a combination of WSL2 + Windows Terminal (version 1.5.10411.0). On a different machine, the same problem does not reproduce with a WSL1 distro. On the same machine, switching to Windows Terminal Preview from Microsoft Store should also fix the problem.

Here are more a few more detailed notes: (I was using Pengwin for WSL on all three machines listed below.)

---

Apologize for not including all the details. Here are the Windows specifications for the desktop machine where I took the screenshot. I was using Windows Terminal version 1.5.10411.0, downloaded directly from Microsoft Store. I am using WSL2 on this machine.

Edition	Windows 10 Pro
Version	20H2
Installed on	‎1/‎31/‎2021
OS build	19042.804
Experience	Windows Feature Experience Pack 120.2212.551.0

Also, with the same version of Windows Terminal from Microsoft Store, the problem is reproduced on a T480 laptop with Win 10 Pro Version 1909. (Well, Pengwin is installed as WSL2 here.)

However, on another Lenovo T480 laptop with the following specifications, the Windows Terminal from the Store should work without a problem.

Edition	Windows 10 Pro
Version	20H2
Installed on	‎2/‎12/‎2021
OS build	19042.804
Experience	Windows Feature Experience Pack 120.2212.551.0

Here is a screenshot from the 2nd T480 laptop with Win 10 Pro Version 20H2. It is clean as it should be.

Note, this is Pengwin installed as WSL1.

---

Looks like the Windows Termianl Preview (version 1.6.10412.0) does not produce the Tmux problem, though. Glad to find another viable alternative emulator.

[llinfeng]

I now attribute the "new variant " of rendering error to vim-prosession, a Vim-plugin. To be more specific, I was including an E0056 character when I ask vim-prosession to update the window name when I enter vim from the command line. The following settings in .vimrc shall reproduce the problem.

let g:prosession_tmux_title = 1
let g:prosession_tmux_title_format = "V󠁖-@@@"

Note, on the 2nd line, there was an E0056 char between V and -. Inspecting the string "V󠁖-@@@" here shall reveal E0056.

For a good number of months, though, the E0056 char has been rendered properly with wsltty. Looks like Windows Terminal (or Preview) cannot handle the E0056 char properly when it is inserted into the status bar for Tmux.

[yveslange]

Hi, got the same issue recently. Everything was working great all those months.
Terminal: 1.6.10571.0
Tmux: 3.0a

[dz14]

I am running into this issue also. It seems to happen when I start my React applications in a tmux split pane and the start up script would automatically open up the React application in Edge. Switching context back into Windows Terminal and I can see this issue. I can fix it simply by closing the terminal, reopening it and re-attaching the running tmux session.

Windows Terminal
Version: 1.6.10571.0
Tmux: 3.0a

[zadjii-msft]

I honestly don't really think there's anything in 1.16.3460 that would have fixed this.... I'd be excited to find out that it was fixed by chance.

v1.15.3465.0...v1.16.3463.0

Maybe:

• Introduce breaking changes to ReadConsoleOutput #13321

okay 200 commits later and that looks like the only one that might affect this. But I'm pretty sure WSL wouldn't be invoking a ReadConsoleOutput at any point. Weird. There are some changes in 1.17 that do more to mess with the buffer. Those changes I'd think would be more likely to improve this. That being said, the repro in #6987 (comment) is still broken in 1.17, so 🤷

[ryuheechul]

I found a weird workaround that works for me.

1. opening tmux with a split in one Terminal tab. Here I see the rendering error.
2. open a new terminal tab and attach to the tmux session. Now the issue has miraculously disappeared

So above works for me too!
And this can be translated to below if you just want to have one terminal at a time:

1. detach from tmux (and quits the terminal as well)
2. open a new terminal and attach to tmux

Steps above are well aligned for my specific Alacritty setup which attaches to tmux when launched - via alias - and that also makes detaching quits the terminal.

And after these steps, it stays fine even after a triggering action that breaks pane in the first place.

---

A triggering action for me is the use of starship with zsh via toggleterm in neovim and this didn't happen with other platforms like macOS but only with WSL. (starship in tmux directly seems to be fine)

This also happens with Alacritty (Windows native) as well as the windows Terminal app.

Also when I see this issue with Tmux, I don't see that with Zellij (possibly because Zellij doesn't support passthrough yet).

[jradam]

Also getting this issue when running any kind of terminal process. Whether using tmux or not. As soon as I have a terminal process running somewhere, glitches start showing up.

The glitches take a while to creep in, but can be triggered instantly by opening a floating window in Vim:

glitches.mp4

[j4james]

@jradam If you can reproduce the issue easily, it would be helpful if you could record your vim session using the Linux script command, and then we can see exactly what it's doing that is triggering the problem.

[jradam]

@j4james sure thing. Here is a video of a working terminal window becoming "corrupted", as well as the script as requested.

glitches.mp4

typescript.zip

[j4james]

@jradam Thanks for that script capture, but you need to run script before you start vim. I know almost nothing about vim, so I'm not really sure what you're doing, but it looks to me like you've started a shell from within vim. All that's been captured is the output of that shell - the yarn execution - and nothing from vim itself.

[jradam]

@j4james no problem, here's a video and scripts showing the complete flow.

There are two scripts, as I ran it again for the new tmux window. I presume the first script would not capture what was happening in a new window. This was in a different directory, so the first script was not overwritten.

• Glitches occur when a terminal process is running in the same Windows Terminal tab you are working in.
• Glitches do not occur if you use a separate Windows Terminal tab to run processes.
• The issue does occur if you are using separate tabs, but connecting to the same tmux session.

To recreate the issue, you have to use something like tmux (or in the case of my previous video, Neovim's built-in terminal) to run a process. In the video below I use tmux. You can see visual glitches start to appear in the numberline on the left once I start editing a file.

When I do it through tmux, opening windows does not instantly cause glitches like in my previous video. But the glitches seem to be of the same type, and either way they slowly get worse over time and spread all over the window - until your code is illegible and you have to restart Windows Terminal.

Hope this helps!

typescript-files.zip

more-glitches.mp4

[j4james]

@jradam That was perfect, thanks. This looks to me like the same problem as #14690. The DISABLE_NEWLINE_AUTO_RETURN mode has been inadvertently reset, so a line feed forces a carriage return, and when tmux or vim try to move the cursor down a line, it's also mistakenly moved to the leftmost column. This results in things being rendered in the wrong place, e.g. when hilighting the import on the second line, it gets redrawn too far to the left.

In your case I'm assuming the mode change was triggered by yarn rather than wslsys (this would be an internal API call, so it's not something I can tell from the script log), but I'm hoping it will also be fixed by PR #14735.

[jradam]

@j4james great! Hopefully that will sort it. Thanks James, looking forward to the next release then.

[sw00]

After almost 3 years and exactly 100 comments later, I believe this has finally been fixed in the latest builds:

OS Name:                   Microsoft Windows 11 Pro
OS Version:                10.0.22621 N/A Build 22621
Windows Terminal Version:  1.16.10262.0
WSL2 OS:                   Ubuntu 20.04.5 LTS (Focal Fossa)
WSL2 Kernel:               Linux x1ce2 5.15.90.1-microsoft-standard-WSL2 #1 SMP Fri Jan 27 02:56:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Tmux Version:              3.0a
Shell:                     fish, version 3.6.0

The new text rendering engine had to be enabled (I think):

Here it is in action:

Though I haven't active in the comments, I've been following it closely as I encounter it daily in my workflow.

I'm happy to declare this issue now resolved and closed. 🖖🏽

[yveslange]

"Redraw entire screen when display updates" was causing me a lot of issues with Tmux, Vim and React-Scripts (the start command). Disabled and everything is fine now.

Windows 10 - Version 21H2 - OS Build 19044.2604
Terminal 1.16.10.261.0
Ubuntu - WSL 2
Tmux 3.0a
NVIM v0.4.3

[inigohidalgo]

FWIW none of the above worked for me. What ended up doing the trick for me was setting

set -ag terminal-overrides ',*:cud1=\E[1B'

in my .tmux.conf