Rendering errors in tmux split panes #9706

@zadjii-msft commented on GitHub (Aug 19, 2020):

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 commented on GitHub (Aug 19, 2020): 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. ![gh-6987](https://user-images.githubusercontent.com/18356694/90652505-bf457180-e203-11ea-9a47-8dfd87f7b556.gif)

claunia commented

@zadjii-msft commented on GitHub (Aug 19, 2020):

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 commented on GitHub (Aug 19, 2020): 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: ![image](https://user-images.githubusercontent.com/18356694/90658401-29144a00-e209-11ea-8bc6-7e028050fc12.png) 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](https://github.com/microsoft/terminal/files/5097579/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!

claunia commented

@zadjii-msft commented on GitHub (Aug 25, 2020):

Ho boy this looks awfully a lot like

Tmux pane content gets garbled after refreshing tmux client #4029

@zadjii-msft commented on GitHub (Aug 25, 2020): Ho boy this looks awfully a lot like Tmux pane content gets garbled after refreshing tmux client #4029

claunia commented

@altjx commented on GitHub (Jan 16, 2021):

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

@altjx commented on GitHub (Jan 16, 2021): Any updates on this? Having the exact same issue pretty consistently as well. Let me know if I can contribute to the troubleshooting process.

claunia commented

@llinfeng commented on GitHub (Feb 21, 2021):

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.

@llinfeng commented on GitHub (Feb 21, 2021): 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. ![image](https://user-images.githubusercontent.com/5890407/108625500-4379eb00-7419-11eb-86d2-3e47f9c83f3e.png) 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](https://github.com/mintty/wsltty).**

claunia commented

@DHowett commented on GitHub (Feb 22, 2021):

@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?

@DHowett commented on GitHub (Feb 22, 2021): @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?

claunia commented

@llinfeng commented on GitHub (Feb 22, 2021):

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 commented on GitHub (Feb 22, 2021): 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. ![image](https://user-images.githubusercontent.com/5890407/108647536-e6b51980-7486-11eb-9625-dd6a839cc084.png) **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.

claunia commented

@llinfeng commented on GitHub (Feb 22, 2021):

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.

@llinfeng commented on GitHub (Feb 22, 2021): I now attribute the "new variant " of rendering error to [vim-prosession](https://github.com/dhruvasagar/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](https://apps.timwhitlock.info/unicode/inspect?s=%22V%F3%A0%81%96-%40%40%40%22) shall reveal `E0056`. For a good number of months, though, the `E0056` char has been rendered properly with [wsltty](https://github.com/mintty/wsltty). Looks like Windows Terminal (or Preview) cannot handle the `E0056` char properly when it is inserted into the status bar for Tmux.

claunia commented

@yveslange commented on GitHub (Mar 23, 2021):

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

@yveslange commented on GitHub (Mar 23, 2021): Hi, got the same issue recently. Everything was working great all those months. Terminal: 1.6.10571.0 Tmux: 3.0a

claunia commented

@dz14 commented on GitHub (Mar 24, 2021):

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

@dz14 commented on GitHub (Mar 24, 2021): 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

claunia commented

@kruser commented on GitHub (Apr 7, 2021):

I had this same issue on the official Windows Terminal, but it is seemingly fixed in the current Windows Terminal Preview v1.7.572.0.

@kruser commented on GitHub (Apr 7, 2021): I had this same issue on the official Windows Terminal, but it is seemingly fixed in the current Windows Terminal Preview v1.7.572.0.

claunia commented

@simeonoff commented on GitHub (Apr 8, 2021):

I had this same issue on the official Windows Terminal, but it is seemingly fixed in the current Windows Terminal Preview v1.7.572.0.

Nope, still a problem for me with that version.

@simeonoff commented on GitHub (Apr 8, 2021): > > > I had this same issue on the official Windows Terminal, but it is seemingly fixed in the current Windows Terminal Preview v1.7.572.0. Nope, still a problem for me with that version.

claunia commented

@AstralJohn commented on GitHub (Apr 12, 2021):

Still having rendering issues using tmux with nvim on Windows Terminal Preview 1.7.572.0
I generally use tmux to split panes
A temporary work around for my issue was to use Windows Terminal's built in split panes
I remapped most of the command shortcuts to be similar to tmux's with the help of this
https://docs.microsoft.com/en-us/windows/terminal/panes

@AstralJohn commented on GitHub (Apr 12, 2021): Still having rendering issues using tmux with nvim on Windows Terminal Preview 1.7.572.0 I generally use tmux to split panes A temporary work around for my issue was to use Windows Terminal's built in split panes I remapped most of the command shortcuts to be similar to tmux's with the help of this https://docs.microsoft.com/en-us/windows/terminal/panes

claunia commented

@kruser commented on GitHub (Apr 14, 2021):

Still having rendering issues using tmux with nvim on Windows Terminal Preview 1.7.572.0
I generally use tmux to split panes
A temporary work around for my issue was to use Windows Terminal's built in split panes
I remapped most of the command shortcuts to be similar to tmux's with the help of this
https://docs.microsoft.com/en-us/windows/terminal/panes

Sorry for the confusion on my comment @simeonoff and @JohnDinhDev. Indeed I am still having issues on 1.7.572.0, just fewer. Using WT's built-in panes doesn't cut it for my workflow since I use vim-slime to send across panes and tmuxinator to quickly reset my environment across many different windows.

@kruser commented on GitHub (Apr 14, 2021): > Still having rendering issues using tmux with nvim on Windows Terminal Preview 1.7.572.0 > I generally use tmux to split panes > A temporary work around for my issue was to use Windows Terminal's built in split panes > I remapped most of the command shortcuts to be similar to tmux's with the help of this > https://docs.microsoft.com/en-us/windows/terminal/panes Sorry for the confusion on [my comment](https://github.com/microsoft/terminal/issues/6987#issuecomment-815072490) @simeonoff and @JohnDinhDev. **Indeed I am still having issues on 1.7.572.0**, just fewer. Using WT's built-in panes doesn't cut it for my workflow since I use vim-slime to send across panes and tmuxinator to quickly reset my environment across many different windows.

claunia commented

@m8ram commented on GitHub (May 19, 2021):

I'm having similar issues.
Windows 10, WSL2
Windows Terminal 1.8.1032.0
Ubuntu 20.04 (fully updated 2021-05-19)
tmux 3.0a

Starting tmux, running commands, clearing the screen (with clear) works fine until I create a split pane (ctrl+b+%).

At that point running clear will clear only parts of the screen. The prompt is not or only partially displayed.
After closing the split pane the screen is properly refreshed again.

I'm using default tmux configuration (no ~/.tmux.conf).

If I ssh into a RHEL8 server first and run tmux (version 2.7) there the same problem occurs.

Note I often notice a similar problem when running vimdiff but I haven't nailed down the exact steps to reproduce that reliably yet.

@m8ram commented on GitHub (May 19, 2021): I'm having similar issues. Windows 10, WSL2 Windows Terminal 1.8.1032.0 Ubuntu 20.04 (fully updated 2021-05-19) tmux 3.0a Starting tmux, running commands, clearing the screen (with `clear`) works fine until I create a split pane (ctrl+b+%). At that point running `clear` will clear only parts of the screen. The prompt is not or only partially displayed. After closing the split pane the screen is properly refreshed again. I'm using default tmux configuration (no `~/.tmux.conf`). If I ssh into a RHEL8 server first and run tmux (version 2.7) there the same problem occurs. Note I often notice a similar problem when running `vimdiff` but I haven't nailed down the exact steps to reproduce that reliably yet.

claunia commented

@j0eii commented on GitHub (Jul 25, 2021):

I have experience the same issue

the split screen function can only work in horizontal split, not vertical split.

@j0eii commented on GitHub (Jul 25, 2021): I have experience the same issue the split screen function can only work in horizontal split, not vertical split. ![image](https://user-images.githubusercontent.com/13985803/126891503-fc08dbfc-a6a0-47b7-865f-d47e15b295aa.png)

claunia commented

@yveslange commented on GitHub (Aug 2, 2021):

Any solution ? Still have this issue :(

@yveslange commented on GitHub (Aug 2, 2021): Any solution ? Still have this issue :(

claunia commented

@HUN220 commented on GitHub (Aug 19, 2021):

I have found that Windows Terminal Preview has been working better for me than Windows Terminal. I've seen one instance where the cursor appears to be slightly before where I'm typing but it's only happened once. You can install it through the Microsoft Store.

Windows Terminal 1.9.1942.0 (Rendering issues)
Windows Terminal Preview 1.10.1933.0 (No rendering issues)
Windows 10, WSL2
Ubuntu 20.04
tmux 3.0a

@HUN220 commented on GitHub (Aug 19, 2021): I have found that `Windows Terminal Preview` has been working better for me than `Windows Terminal`. I've seen one instance where the cursor appears to be slightly before where I'm typing but it's only happened once. You can install it through the Microsoft Store. Windows Terminal 1.9.1942.0 _(Rendering issues)_ Windows Terminal Preview 1.10.1933.0 **(No rendering issues)** Windows 10, WSL2 Ubuntu 20.04 tmux 3.0a

claunia commented

@zadjii-msft commented on GitHub (Aug 19, 2021):

FWIW, this would be easier to debug if we had solid repro steps. The repro is flakey (and heck, I couldn't get it to happen again while playing with the Terminal this morning), which is part of the reason this is so hard to fix.

My theory is that it's still related to #6901/#7028/#7253/#10130, and the slew of bugs in #5800. #4029 is also probably the same thing, but the two threads have diverged a decent amount so it's impossible to say for sure.

@zadjii-msft commented on GitHub (Aug 19, 2021): FWIW, this would be easier to debug if we had solid repro steps. The repro is flakey (and heck, I couldn't get it to happen again while playing with the Terminal this morning), which is part of the reason this is so hard to fix. My theory is that it's still related to #6901/#7028/#7253/#10130, and the slew of bugs in #5800. #4029 is also probably the same thing, but the two threads have diverged a decent amount so it's impossible to say for sure.

claunia commented

@j0eii commented on GitHub (Aug 19, 2021):

I think this issue can be closed because I am now working with win terminal flawlessly. :)

big thanks to msft terminal dev team.

@j0eii commented on GitHub (Aug 19, 2021): I think this issue can be closed because I am now working with win terminal flawlessly. :) ![image](https://user-images.githubusercontent.com/13985803/130134351-15af5d16-c677-4afa-bb0b-f5f8171304aa.png) big thanks to msft terminal dev team.

claunia commented

@j0eii commented on GitHub (Aug 19, 2021):

This issue is related to missing a redraw method call upon tmux history / size change..
I notice that now the redraw method is called to fix this, so if there is no new issues, I believe it can be closed.

👍

@j0eii commented on GitHub (Aug 19, 2021): This issue is related to missing a redraw method call upon tmux history / size change.. I notice that now the redraw method is called to fix this, so if there is no new issues, I believe it can be closed. 👍

claunia commented

@G-Rath commented on GitHub (Aug 19, 2021):

@zadjii-msft I think some of the more common render errors I've noticed when using tmux have gone away with the latest (non-preview) version of terminal, but I definitely seem to still be having non-perfect rendering with tmux which I'm happy to help try and get reproductions for, though I may need some guidance as I don't have a strong understanding on how terminals actually work 😅

I'm also not sure if the problems I'm seeing are actually with Windows Terminal or something else such as maybe I'm using a font that doesn't support a specific character (I should be using the stock settings but have had issues in the past where programs decided to stick with an older font after updating).

A common render error I can re-produce is with running bundle exec rails console:

The green divider line on the right is broken, which "follows" that section of console output:

While not a major error, often when things are more wild there's usually some spillagee of text as well onto the other side of the pane - my typical layout is having rails s, docker, and bin/webpack-dev-server which all tend to spit out a lot of colorful logs as I work.

@G-Rath commented on GitHub (Aug 19, 2021): @zadjii-msft I _think_ some of the more common render errors I've noticed when using tmux have gone away with the latest (non-preview) version of terminal, but I definitely seem to still be having non-perfect rendering with tmux which I'm happy to help try and get reproductions for, though I may need some guidance as I don't have a strong understanding on how terminals actually work 😅 I'm also not sure if the problems I'm seeing are actually with Windows Terminal or something else such as maybe I'm using a font that doesn't support a specific character (I should be using the stock settings but have had issues in the past where programs decided to stick with an older font after updating). A common render error I can re-produce is with running `bundle exec rails console`: ![image](https://user-images.githubusercontent.com/3151613/130137476-af0938b3-a5a9-470f-bb1c-5e4d6902b78e.png) The green divider line on the right is broken, which "follows" that section of console output: ![image](https://user-images.githubusercontent.com/3151613/130137662-90a2fb09-55f4-4423-9e51-3c1587c0a57b.png) While not a major error, often when things are more wild there's usually some spillagee of text as well onto the other side of the pane - my typical layout is having `rails s`, `docker`, and `bin/webpack-dev-server` which all tend to spit out a lot of colorful logs as I work.

claunia commented

@AstralJohn commented on GitHub (Sep 7, 2021):

Still having issues with split panes
All I did was ctrl-b + % to split panes, and then type ls, then enter

tmux 3.0a
Windows Terminal Preview
Version: 1.11.2421.0

@AstralJohn commented on GitHub (Sep 7, 2021): ![Untitled mp4](https://user-images.githubusercontent.com/37444633/132397385-569230d2-2ec1-4b0c-b677-8832dbdcd946.gif) Still having issues with split panes All I did was `ctrl-b + %` to split panes, and then type ls, then enter ``` tmux 3.0a Windows Terminal Preview Version: 1.11.2421.0 ```

claunia commented

@m8ram commented on GitHub (Sep 8, 2021):

Like @JohnDinhDev split panes in tmux still cause rendering issues

Windows Terminal Preview
Version: 1.11.2421.0
Ubuntu 20.04
tmux 3.0a
Simply split the panes using ctrl-b + % and run e.g. ls or less

Running vimdiff inside tmux often causes problems as well but I can't reproduce that on command.

@m8ram commented on GitHub (Sep 8, 2021): Like @JohnDinhDev split panes in tmux still cause rendering issues Windows Terminal Preview Version: 1.11.2421.0 Ubuntu 20.04 tmux 3.0a Simply split the panes using `ctrl-b + %` and run e.g. ls or less Running `vimdiff` inside tmux often causes problems as well but I can't reproduce that on command.

claunia commented

@yveslange commented on GitHub (Sep 8, 2021):

NOT WORKING
Strange, got the issue again but doing those steps resolved my issues :O

Installed Nerd Font Hack (i don't think it is this resolving the issue)
- Go to the setting and set the windows to 180 columns, press save
Change the theme to solarized dark (i don't think it is this resolving the issue), press save
- Go to the setting and set the windows to 120 columns back, press save

No more issue... 👯

I have the intuition that changing the columns size fixed my issue

UPDATE: After 5 days, now I have the issue back again :(

@yveslange commented on GitHub (Sep 8, 2021): **NOT WORKING** Strange, got the issue again but doing those steps resolved my issues :O - Installed Nerd Font Hack (i don't think it is this resolving the issue) **- Go to the setting and set the windows to 180 columns**, press save - Change the theme to solarized dark (i don't think it is this resolving the issue), press save **- Go to the setting and set the windows to 120 columns back**, press save No more issue... 👯 I have the intuition that changing the columns size fixed my issue **UPDATE: After 5 days, now I have the issue back again :(**

claunia commented

@m8ram commented on GitHub (Sep 10, 2021):

Just changing the columns size has no effect for me.
I closed and restarted the shell and even closed and restarted the terminal application completely.
I'm using solarized light as color scheme and Consolas as font in case that matters.

@m8ram commented on GitHub (Sep 10, 2021): Just changing the columns size has no effect for me. I closed and restarted the shell and even closed and restarted the terminal application completely. I'm using solarized light as color scheme and Consolas as font in case that matters.

claunia commented

2026-01-31 02:01:33 +00:00

@j4james commented on GitHub (Sep 10, 2021):

This is still easy to break by using a unicode sequence that Windows Terminal doesn't render with the correct width. For example, try something like this:

printf 'x\ufe0e%.0s' {1..100}

You'll see the output from the left pane goes straight across into the right pane like this:

If you're using a fancy prompt with emoji in (like the cloud in @G-Rath's screenshot above), I suspect that might be the cause of your tmux rendering problems.

@j4james commented on GitHub (Sep 10, 2021): This is still easy to break by using a unicode sequence that Windows Terminal doesn't render with the correct width. For example, try something like this: ``` printf 'x\ufe0e%.0s' {1..100} ``` You'll see the output from the left pane goes straight across into the right pane like this: ![image](https://user-images.githubusercontent.com/4181424/132925177-f7a2c81f-1665-4db2-994a-fa0aa39ba9c1.png) If you're using a fancy prompt with emoji in (like the cloud in @G-Rath's screenshot above), I suspect that might be the cause of your tmux rendering problems.

claunia commented

@yveslange commented on GitHub (Sep 13, 2021):

Windows 11
Windows Terminal 1.10.2383.0
Tmux: 3.0a
Ubuntu: 20.04.3 LTS

Still having the issue :(

Sadly without any solution, it is really difficult to develop with Microsoft Terminal and tmux.
I am back to mintty/wsltty

@yveslange commented on GitHub (Sep 13, 2021): Windows 11 Windows Terminal 1.10.2383.0 Tmux: 3.0a Ubuntu: 20.04.3 LTS Still having the issue :( Sadly without any solution, it is really difficult to develop with Microsoft Terminal and tmux. I am back to mintty/wsltty

claunia commented

2026-01-31 02:01:33 +00:00

@exodru commented on GitHub (Oct 14, 2021):

Windows 11
Terminal version: 1.10.2714.0
Tmux 3.0a
Ubuntu: 20.04.3 LTS

Same issue, glitchy tmux.

@exodru commented on GitHub (Oct 14, 2021): Windows 11 Terminal version: 1.10.2714.0 Tmux 3.0a Ubuntu: 20.04.3 LTS Same issue, glitchy tmux.

claunia commented

@dries commented on GitHub (Oct 15, 2021):

Windows 10 Pro
Terminal version: 1.10.2714.0
Tmux: 2.8-3
Debian: 10.10 WSL2

Same issue, was gone for a few months and now returned possibly due to some update of something.

Edit: updating tot debian 11/tmux 3.1c didn't help. The issue did reappear (on a fresh tmux session) upon running yarn start in a tmux pane for a create-react-app application.

@dries commented on GitHub (Oct 15, 2021): Windows 10 Pro Terminal version: 1.10.2714.0 Tmux: 2.8-3 Debian: 10.10 WSL2 Same issue, was gone for a few months and now returned possibly due to some update of something. Edit: updating tot debian 11/tmux 3.1c didn't help. The issue did reappear (on a fresh tmux session) upon running `yarn start` in a tmux pane for a ` create-react-app` application.

claunia commented

@m4tt72 commented on GitHub (Oct 24, 2021):

I had the same issue for a year now until I set LANG=en_US.UTF8 using sudo update-locale LANG=en_US.UTF8 as well as export LANG=en_US.UTF8

I also have set -g default-terminal "xterm-256color" in my .tmux.conf
and tmux aliased to alias tmux="TERM=xterm-256color tmux -2"

Windows 11 Build 22000.282
Windows Terminal: 1.102714.0
Tmux: tmux 3.0a
OS: Ubuntu 20.04.3 LTS on Windows 10 x86_64

Edit: Nope it doesn't work :/

@m4tt72 commented on GitHub (Oct 24, 2021): I had the same issue for a year now until I set `LANG=en_US.UTF8` using `sudo update-locale LANG=en_US.UTF8` as well as `export LANG=en_US.UTF8` I also have `set -g default-terminal "xterm-256color"` in my `.tmux.conf` and tmux aliased to `alias tmux="TERM=xterm-256color tmux -2"` Windows 11 Build 22000.282 Windows Terminal: 1.102714.0 Tmux: tmux 3.0a OS: Ubuntu 20.04.3 LTS on Windows 10 x86_64 Edit: Nope it doesn't work :/

claunia commented

@yueyingjuesha commented on GitHub (Nov 11, 2021):

Want to report that even with neovim split, still produced the same kind of display artifacts

@yueyingjuesha commented on GitHub (Nov 11, 2021): Want to report that even with neovim split, still produced the same kind of display artifacts

claunia commented

@yueyingjuesha commented on GitHub (Nov 12, 2021):

I solve it by adding "experimental.rendering.forceFullRepaint": true, to json setting file

@yueyingjuesha commented on GitHub (Nov 12, 2021): I solve it by adding "experimental.rendering.forceFullRepaint": true, to json setting file

claunia commented

@SuperSandro2000 commented on GitHub (Nov 12, 2021):

I solve it by adding "experimental.rendering.forceFullRepaint": true, to json setting file

Thanks! works for me, too.

@SuperSandro2000 commented on GitHub (Nov 12, 2021): > I solve it by adding "experimental.rendering.forceFullRepaint": true, to json setting file Thanks! works for me, too.

claunia commented

@m8ram commented on GitHub (Dec 20, 2021):

First test looked promising, but unfortunately I get the same rendering errors today with the option set.

Am I correct to assume that the property "experimental.rendering.forceFullRepaint": true, needs to be added to the WSL profile item of the "profiles" list?

e.g.

            {
                "colorScheme": "Solarized Light",
                "experimental.retroTerminalEffect": false,
                "experimental.rendering.forceFullRepaint": true,
                "font": 
                {
                    "face": "Consolas",
                    "size": 14
                },
                "guid": "{07b52e3e-de2c-5db4-bd2d-ba144ed6c273}",
                "hidden": false,
                "name": "Ubuntu-20.04",
                "source": "Windows.Terminal.Wsl",
                "startingDirectory": "//wsl$/Ubuntu-20.04/home/me/"
            },

@m8ram commented on GitHub (Dec 20, 2021): First test looked promising, but unfortunately I get the same rendering errors today with the option set. Am I correct to assume that the property `"experimental.rendering.forceFullRepaint": true,` needs to be added to the WSL profile item of the `"profiles"` list? e.g. ``` { "colorScheme": "Solarized Light", "experimental.retroTerminalEffect": false, "experimental.rendering.forceFullRepaint": true, "font": { "face": "Consolas", "size": 14 }, "guid": "{07b52e3e-de2c-5db4-bd2d-ba144ed6c273}", "hidden": false, "name": "Ubuntu-20.04", "source": "Windows.Terminal.Wsl", "startingDirectory": "//wsl$/Ubuntu-20.04/home/me/" }, ```

claunia commented

@crusoexia commented on GitHub (Dec 27, 2021):

"experimental.rendering.forceFullRepaint": true doesn't work for me too.

Windows 11 build: 22000.376
Windows terminal: 1.11.3471.0

@crusoexia commented on GitHub (Dec 27, 2021): `"experimental.rendering.forceFullRepaint": true` doesn't work for me too. Windows 11 build: `22000.376` Windows terminal: `1.11.3471.0`

claunia commented

@zadjii-msft commented on GitHub (Jan 3, 2022):

FWIW, we're pretty confident that "experimental.rendering.forceFullRepaint": true shouldn't actually fix this. It might coincidentally fix this, by forcing a reboot of the Terminal, and maybe makes it harder to get into this state. But presumably this is due to a desync between the ConPTY buffer and the Terminal one, and that's not something forceFullRepaint would affect.

@zadjii-msft commented on GitHub (Jan 3, 2022): FWIW, we're pretty confident that ` "experimental.rendering.forceFullRepaint": true` shouldn't _actually_ fix this. It might _coincidentally_ fix this, by forcing a reboot of the Terminal, and maybe makes it harder to get into this state. But presumably this is due to a desync between the ConPTY buffer and the Terminal one, and that's not something `forceFullRepaint` would affect.

claunia commented

@bcawrse commented on GitHub (Jan 5, 2022):

This bug occurs sometimes for me. Horizontal splits always work, vertical ones sometimes bomb.

As a temporary workaround I've found that detaching my tmux session, then reattaching to it, resolves the problem for me. Not my favorite, but at least it's something so I can move past the bug.

Windows 10 v21H2 build: 19044.1415
Windows Feature Experience Pack: 120.2212.3920.0
Windows Terminal: 1.11.3471.0
WSL: Version 2, Ubuntu-18.04, Kernel v5.10.60.1

@bcawrse commented on GitHub (Jan 5, 2022): This bug occurs _sometimes_ for me. Horizontal splits always work, vertical ones sometimes bomb. As a temporary workaround I've found that detaching my tmux session, then reattaching to it, resolves the problem for me. Not my favorite, but at least it's something so I can move past the bug. Windows 10 v21H2 build: `19044.1415` Windows Feature Experience Pack: `120.2212.3920.0` Windows Terminal: `1.11.3471.0` WSL: `Version 2, Ubuntu-18.04, Kernel v5.10.60.1`

claunia commented

@CodingdAwn commented on GitHub (Jan 11, 2022):

"experimental.rendering.forceFullRepaint": true,
Thanks! works for me, too.

@CodingdAwn commented on GitHub (Jan 11, 2022): > "experimental.rendering.forceFullRepaint": true, Thanks! works for me, too.

claunia commented

@lsevero commented on GitHub (Jan 26, 2022):

I solve it by adding "experimental.rendering.forceFullRepaint": true, to json setting file

Worked for me as well, thanks a lot.

@lsevero commented on GitHub (Jan 26, 2022): > I solve it by adding "experimental.rendering.forceFullRepaint": true, to json setting file Worked for me as well, thanks a lot.

claunia commented

@rcx commented on GitHub (Feb 2, 2022):

The forceFullRepaint workaround works for me and also fixes weird ghosting issues with in nano as well.

@rcx commented on GitHub (Feb 2, 2022): The forceFullRepaint workaround works for me and also fixes weird ghosting issues with in nano as well.

claunia commented

@delucca commented on GitHub (Feb 19, 2022):

No updates on this?

@delucca commented on GitHub (Feb 19, 2022): No updates on this?

claunia commented

@zadjii-msft commented on GitHub (Feb 24, 2022):

Nope. We'll make sure to update this thread when there is.

I couldn't get a consistent set of repro steps for this the last time I investigated this: https://github.com/microsoft/terminal/issues/6987#issuecomment-676510163. I haven't had a chance to try again since. If someone could find an exact set of "use these settings, this tmux config, run this, that another" to repro this consistently, that would be much appreciated.

I suspect it has something to do with wide/narrow characters like the ones commonly found in nerdfonts powerline setups, but a consistent repro without those should also be possible.

@zadjii-msft commented on GitHub (Feb 24, 2022): Nope. We'll make sure to update this thread when there is. I couldn't get a consistent set of repro steps for this the last time I investigated this: https://github.com/microsoft/terminal/issues/6987#issuecomment-676510163. I haven't had a chance to try again since. If someone could find an exact set of "use these settings, this tmux config, run this, that another" to repro this consistently, that would be much appreciated. I suspect it has something to do with wide/narrow characters like the ones commonly found in nerdfonts powerline setups, but a consistent repro without those should also be possible.

claunia commented

@m8ram commented on GitHub (Mar 11, 2022):

My environment and steps to reproduce
Windows 10 Pro 21H2 (OS build 19044.1526)
Windows Terminal Preview Version: 1.13.10395.0
Ubuntu 20.04 on Windows

I believe I have WSL 2 installed but the following makes me wonder:

PS C:\Users\bmertens> wsl -l -v
  NAME                   STATE           VERSION
* Ubuntu-20.04           Running         1
  docker-desktop-data    Running         2
  docker-desktop         Running         2

I have the Ubuntu profile set to use the Solarized light theme and Consolas as font, font size 14.

tmux version tmux 3.0a
TERM: xterm-256color

To reproduce:

launch tmux
split panes using CTRL+B+%
run ls -l in the left pane (often not even necessary)
switch to the right pane
run less on any text file

This will garble the display of the left pane almost every time. If not close less and start it again

tmux config:

$ cat ~/.tmux.conf
set -g default-terminal "screen-256color"
set -g allow-rename on

I have tried to enable both "Redraw entire screen when display updates" and "Use software rendering" separately and together but the issue remains.

Reproducing in vimdiff is less consistent. When I try to reproduce it for this case it works fine and while I'm in the middle of actual work it will often trigger the problem.

HTH

@m8ram commented on GitHub (Mar 11, 2022): My environment and steps to reproduce Windows 10 Pro 21H2 (OS build 19044.1526) Windows Terminal Preview Version: 1.13.10395.0 Ubuntu 20.04 on Windows I believe I have WSL 2 installed but the following makes me wonder: ``` PS C:\Users\bmertens> wsl -l -v NAME STATE VERSION * Ubuntu-20.04 Running 1 docker-desktop-data Running 2 docker-desktop Running 2 ``` I have the Ubuntu profile set to use the Solarized light theme and Consolas as font, font size 14. tmux version tmux 3.0a TERM: xterm-256color To reproduce: - launch tmux - split panes using `CTRL+B+%` - run `ls -l` in the left pane (often not even necessary) - switch to the right pane - run `less` on any text file This will garble the display of the left pane almost every time. If not close `less` and start it again tmux config: ``` $ cat ~/.tmux.conf set -g default-terminal "screen-256color" set -g allow-rename on ``` I have tried to enable both "Redraw entire screen when display updates" and "Use software rendering" separately and together but the issue remains. Reproducing in `vimdiff` is less consistent. When I try to reproduce it for this case it works fine and while I'm in the middle of actual work it will often trigger the problem. HTH

claunia commented

@zadjii-msft commented on GitHub (Mar 11, 2022):

@m8ram do you have any sort of prompt customization going on? Which shell are you using (bash, zsh, fish)? Part of my only theory is that this is caused by some powerline or other specific character, so knowing what's at the prompt in these tmux panes might also be helpful.

@zadjii-msft commented on GitHub (Mar 11, 2022): @m8ram do you have any sort of prompt customization going on? Which shell are you using (bash, zsh, fish)? Part of my only theory is that this is caused by some powerline or other specific character, so knowing what's at the prompt in these tmux panes might also be helpful.

claunia commented

@smerrill commented on GitHub (Mar 11, 2022):

I also have issues with bad rendering bugs when scrolling tmux buffers or editing in vim when there are tmux split panes active. I do currently have a powerline-enabled prompt, but will test without later and report back.

Also, shout out to the excellent suggestion of https://github.com/mintty/wsltty, which has fixed all my tmux rendering woes.

@smerrill commented on GitHub (Mar 11, 2022): I also have issues with bad rendering bugs when scrolling tmux buffers or editing in vim when there are tmux split panes active. I do currently have a powerline-enabled prompt, but will test without later and report back. Also, shout out to the excellent suggestion of https://github.com/mintty/wsltty, which has fixed all my tmux rendering woes.

claunia commented

@mohitt commented on GitHub (Mar 25, 2022):

I am also having the same issue.

I have to restart the windows terminal, and I am using the pre version.

When I restart terminal it goes away and after sometime it comes back. Restart terminal it goes away.

Pretty annoying. Let me give wsltty a shot

@mohitt commented on GitHub (Mar 25, 2022): I am also having the same issue. I have to restart the windows terminal, and I am using the `pre` version. When I restart terminal it goes away and after sometime it comes back. Restart terminal it goes away. Pretty annoying. Let me give wsltty a shot

claunia commented

@chrisl8 commented on GitHub (Apr 5, 2022):

I think that @zadjii-msft is right that at least in some cases this is caused by advanced prompt setups with things such as powerline.

I did some testing today and was unable to reproduce the issue for myself if I set my shell to bash with no customization, but with my normal zsh + loads of nonsense, it is essentially unusable with a vertical split.

I am using zsh with Oh My ZSH!

My guess is that if you just set up the minimal Oh My ZSH! setup, it will replicate the issue.

Let me know if there is anything I can do to help move this along in the way of testing or providing examples of how to reproduce it.

@chrisl8 commented on GitHub (Apr 5, 2022): I think that @zadjii-msft is right that at least in some cases this is caused by advanced prompt setups with things such as powerline. I did some testing today and was unable to reproduce the issue for myself if I set my shell to bash with no customization, but with my normal zsh + loads of nonsense, it is essentially unusable with a vertical split. I am using zsh with [Oh My ZSH!](https://ohmyz.sh/ ) My guess is that if you just set up the minimal [Oh My ZSH!](https://ohmyz.sh/ ) setup, it will replicate the issue. Let me know if there is anything I can do to help move this along in the way of testing or providing examples of how to reproduce it.

claunia commented

@sandman-battelle commented on GitHub (Apr 25, 2022):

I couldn't get a consistent set of repro steps for this the last time I investigated this: #6987 (comment). I haven't had a chance to try again since. If someone could find an exact set of "use these settings, this tmux config, run this, that another" to repro this consistently, that would be much appreciated.

@j4james provided this one liner that consistently breaks tmux on WSL for me

printf 'x\ufe0e%.0s' {1..100}

@sandman-battelle commented on GitHub (Apr 25, 2022): > I couldn't get a consistent set of repro steps for this the last time I investigated this: [#6987 (comment)](https://github.com/microsoft/terminal/issues/6987#issuecomment-676510163). I haven't had a chance to try again since. If someone could find an exact set of "use these settings, this tmux config, run this, that another" to repro this consistently, that would be much appreciated. @j4james provided this one liner that consistently breaks tmux on WSL for me ```sh printf 'x\ufe0e%.0s' {1..100} ```

claunia commented

@m8ram commented on GitHub (May 2, 2022):

@m8ram do you have any sort of prompt customization going on? Which shell are you using (bash, zsh, fish)? Part of my only theory is that this is caused by some powerline or other specific character, so knowing what's at the prompt in these tmux panes might also be helpful.

Apologies for the late reply.
I have no prompt customization.
I do start an ssh agent automatically but even without that I can reproduce the problem with @j4james ' printf command.

For completeness:

$ echo $PS1
${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$
$ echo $PS2
>

Color scheme is Solarized Light, Font is consolas, by I can reproduce with theme Cambell and Font Cascadia Code or Courier New as well.

@m8ram commented on GitHub (May 2, 2022): > @m8ram do you have any sort of prompt customization going on? Which shell are you using (bash, zsh, fish)? Part of my only theory is that this is caused by some powerline or other specific character, so knowing what's at the prompt in these tmux panes might also be helpful. Apologies for the late reply. I have no prompt customization. I do start an ssh agent automatically but even without that I can reproduce the problem with @j4james ' printf command. For completeness: ``` $ echo $PS1 ${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ $ echo $PS2 > ``` Color scheme is Solarized Light, Font is consolas, by I can reproduce with theme Cambell and Font Cascadia Code or Courier New as well.

claunia commented

@zadjii-msft commented on GitHub (May 2, 2022):

For example, try something like this:
printf 'x\ufe0e%.0s' {1..100}
You'll see the output from the left pane goes straight across into the right pane

How did I not see this before? Maybe GH auto-collapsing bits of the thread? Dang that repro's all the way back to conhost:

So that's at least the root of the issue. Now how do we reconcile what conhost thinks here with what tmux thinks? That's the hard question.

@zadjii-msft commented on GitHub (May 2, 2022): > For example, try something like this: > > ``` > printf 'x\ufe0e%.0s' {1..100} > ``` > > You'll see the output from the left pane goes straight across into the right pane How did I not see this before? Maybe GH auto-collapsing bits of the thread? Dang that repro's all the way back to conhost: ![image](https://user-images.githubusercontent.com/18356694/166230410-8033879a-706e-4995-ac0a-9575b3d93373.png) So that's at least the root of the issue. Now how do we reconcile what conhost thinks here with what tmux thinks? That's the hard question.

claunia commented

@j4james commented on GitHub (May 2, 2022):

Now how do we reconcile what conhost thinks here with what tmux thinks? That's the hard question.

I've been assuming this would all be resolved by the epic buffer rewrite from issue #8000. Right now we can't handle characters or character combinations that occupy two positions in the buffer, but are only meant to occupy one cell on the screen (zero width joiners are probably one case, surrogate pairs that are meant to render as narrow-width glyphs would be another).

But I've been thinking, if the buffer rewrite isn't going to happen anytime soon, we might be able to hack a quick fix by just not storing those kinds of characters in the first place. Basically if we receive a zero-width joiner, just drop it. Similarly for narrow-width surrogate pairs, we could store a single error glyph instead. It's obviously not going to look right, but at least it won't then break the whole layout of the page.

There may still be other problems that are causing tmux to break, but I think it would help immensely if we could rule out all the obvious buffer-related causes.

@j4james commented on GitHub (May 2, 2022): > Now how do we reconcile what conhost thinks here with what tmux thinks? That's the hard question. I've been assuming this would all be resolved by the epic buffer rewrite from issue #8000. Right now we can't handle characters or character combinations that occupy two positions in the buffer, but are only meant to occupy one cell on the screen (zero width joiners are probably one case, surrogate pairs that are meant to render as narrow-width glyphs would be another). But I've been thinking, if the buffer rewrite isn't going to happen anytime soon, we might be able to hack a quick fix by just not storing those kinds of characters in the first place. Basically if we receive a zero-width joiner, just drop it. Similarly for narrow-width surrogate pairs, we could store a single error glyph instead. It's obviously not going to look right, but at least it won't then break the whole layout of the page. There may still be other problems that are causing tmux to break, but I think it would help immensely if we could rule out all the obvious buffer-related causes.

claunia commented

@marwan38 commented on GitHub (May 28, 2022):

Nice to see the issue i'm battling with wasn't just me. I see a similar issue within neovim as well. I initially thought it was the terminal overrides in the tmux config.

Alacritty 0.10.1 on Windows 11

@marwan38 commented on GitHub (May 28, 2022): Nice to see the issue i'm battling with wasn't just me. I see a similar issue within neovim as well. I initially thought it was the terminal overrides in the tmux config. Alacritty 0.10.1 on Windows 11

claunia commented

https://user-images.githubusercontent.com/47204120/171546527-4565676b-f6fa-4dc8-af68-339ab919d0dc.mp4

@princejoogie commented on GitHub (Jun 2, 2022):

Nice to see the issue i'm battling with wasn't just me. I see a similar issue within neovim as well. I initially thought it was the terminal overrides in the tmux config.

Alacritty 0.10.1 on Windows 11

I am experiencing this issue in both windows terminal and alacritty.

Referencing an alacritty issue (https://github.com/alacritty/alacritty/issues/5483) as it says it might be a windows bug not alacritty/terminal

Here is what happens in Alacritty

v0.10.1
Windows 11
WSL2 Ubuntu 20.04

NOTE: Weirdly enough, the render issue only happens in vertical tmux splits not horizontal (at least in my case)

@princejoogie commented on GitHub (Jun 2, 2022): > Nice to see the issue i'm battling with wasn't just me. I see a similar issue within neovim as well. I initially thought it was the terminal overrides in the tmux config. > > Alacritty 0.10.1 on Windows 11 I am experiencing this issue in both windows terminal and alacritty. Referencing an alacritty issue (https://github.com/alacritty/alacritty/issues/5483) as it says it might be a windows bug not alacritty/terminal Here is what happens in Alacritty - v0.10.1 - Windows 11 - WSL2 Ubuntu 20.04 https://user-images.githubusercontent.com/47204120/171546527-4565676b-f6fa-4dc8-af68-339ab919d0dc.mp4 **NOTE**: Weirdly enough, the render issue only happens in vertical tmux splits not horizontal (at least in my case)

claunia commented

@3N4N commented on GitHub (Jun 19, 2022):

I am experiencing this bug as well in tmux v3.2a. But have you tried tmux v3.3a, @princejoogie? It appears to not cause that issue. I can't tell if the bug is fixed or if only my repro case is fixed.

@3N4N commented on GitHub (Jun 19, 2022): I am experiencing this bug as well in tmux v3.2a. But have you tried tmux v3.3a, @princejoogie? It appears to not cause that issue. I can't tell if the bug is fixed or if only my repro case is fixed.

claunia commented

@Knapptr commented on GitHub (Jun 20, 2022):

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

This happens here as well. WSL 2, Ubuntu22.04, Windows Terminal Version: 1.13.11431.0. Tmux 3.2A.
Closing the terminal window or detaching from tmux resolves the issue.something seems to be happening when firefox is launched for the CRA dev server.

Launching firefox directly from the Ubuntu shell does not cause the issue.

Setting the CRA start script to "start": "BROWSER=none react-scripts start prevents the browser from auto-launching, and prevents the issue.

@Knapptr commented on GitHub (Jun 20, 2022): > 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 This happens here as well. WSL 2, Ubuntu22.04, Windows Terminal Version: 1.13.11431.0. Tmux 3.2A. Closing the terminal window or detaching from tmux resolves the issue.*something* seems to be happening when firefox is launched for the CRA dev server. Launching firefox directly from the Ubuntu shell does not cause the issue. Setting the CRA start script to `"start": "BROWSER=none react-scripts start` prevents the browser from auto-launching, and prevents the issue.

claunia commented

@vitale232 commented on GitHub (Jun 20, 2022):

I suspect it has something to do with wide/narrow characters like the ones commonly found in nerdfonts powerline setups, but a consistent repro without those should also be possible.

Reading through this thread, zadjii's comment regarding nerdfonts combined with some other comments about line wrapping struck a chord.

I am using WSL2 Ubuntu 20.04 on Windows 10, and I have Oh My Posh installed to theme my shell. I was consistently running into rendering issues with tmux. Split panes were a mess, and neovim completions were having rendering artifacts too. Quite distracting.

By simply switching my oh my posh theme, I seem to have a lot more predictable rendering within my tmux session. I was previously using the thecyberden theme from oh my posh, which renders the command's time right aligned on every command. Now, I'm using a theme that does not have the right-aligned text (e.g. darkblood), and I'm unable to replicate the rendering issues. Hopefully this lasts! And hopefully this helps someone else...

Update 6h later: I spent most of the day with the different theme, and things are definitely better, but the bug is very much present

@vitale232 commented on GitHub (Jun 20, 2022): > I suspect it has something to do with wide/narrow characters like the ones commonly found in nerdfonts powerline setups, but a consistent repro without those should also be possible. Reading through this thread, zadjii's comment regarding nerdfonts combined with some other comments about line wrapping struck a chord. I am using WSL2 Ubuntu 20.04 on Windows 10, and I have Oh My Posh installed to theme my shell. I was consistently running into rendering issues with tmux. Split panes were a mess, and neovim completions were having rendering artifacts too. Quite distracting. By simply switching my oh my posh theme, I seem to have a lot more predictable rendering within my tmux session. I was previously using the `thecyberden` theme from oh my posh, which renders the command's time _right aligned_ on every command. Now, I'm using a theme that does not have the right-aligned text (e.g. `darkblood`), and I'm unable to replicate the rendering issues. Hopefully this lasts! And hopefully this helps someone else... Update 6h later: I spent most of the day with the different theme, and things are definitely _better_, but the bug is very much present

claunia commented

@marwan38 commented on GitHub (Jun 20, 2022):

I suspect it has something to do with wide/narrow characters like the ones commonly found in nerdfonts powerline setups, but a consistent repro without those should also be possible.

Reading through this thread, zadjii's comment regarding nerdfonts combined with some other comments about line wrapping struck a chord.

I am using WSL2 Ubuntu 20.04 on Windows 10, and I have Oh My Posh installed to theme my shell. I was consistently running into rendering issues with tmux. Split panes were a mess, and neovim completions were having rendering artifacts too. Quite distracting.

By simply switching my oh my posh theme, I seem to have a lot more predictable rendering within my tmux session. I was previously using the thecyberden theme from oh my posh, which renders the command's time right aligned on every command. Now, I'm using a theme that does not have the right-aligned text (e.g. darkblood), and I'm unable to replicate the rendering issues. Hopefully this lasts! And hopefully this helps someone else...

Just for context: I am writing this at 3:45 AM as I woke up because of how cold it is and I was hungry. I received an email, and as soon as I read your comment, I knew that this was the fix.

I have set up p10k as my zsh theme, and it does include right aligned text. I've disabled it and now the rendering issue has been fixed. I need to give it a little bit more time, but, there's no more weird artifacts with split windows, my neovim is totally fine. Thank you!!

EDIT: Spoke too soon :) Still facing the issue. Going to try to update tmux, currently on 3.0a

@marwan38 commented on GitHub (Jun 20, 2022): > > I suspect it has something to do with wide/narrow characters like the ones commonly found in nerdfonts powerline setups, but a consistent repro without those should also be possible. > > Reading through this thread, zadjii's comment regarding nerdfonts combined with some other comments about line wrapping struck a chord. > > I am using WSL2 Ubuntu 20.04 on Windows 10, and I have Oh My Posh installed to theme my shell. I was consistently running into rendering issues with tmux. Split panes were a mess, and neovim completions were having rendering artifacts too. Quite distracting. > > By simply switching my oh my posh theme, I seem to have a lot more predictable rendering within my tmux session. I was previously using the `thecyberden` theme from oh my posh, which renders the command's time _right aligned_ on every command. Now, I'm using a theme that does not have the right-aligned text (e.g. `darkblood`), and I'm unable to replicate the rendering issues. Hopefully this lasts! And hopefully this helps someone else... Just for context: I am writing this at 3:45 AM as I woke up because of how cold it is and I was hungry. I received an email, and as soon as I read your comment, I knew that this was the fix. I have set up p10k as my zsh theme, and it does include _right aligned_ text. I've disabled it and now the rendering issue has been fixed. I need to give it a little bit more time, but, there's no more weird artifacts with split windows, my neovim is totally fine. Thank you!! EDIT: Spoke too soon :) Still facing the issue. Going to try to update tmux, currently on 3.0a

claunia commented

2026-01-31 02:01:40 +00:00

@rodrigomartin commented on GitHub (Jul 6, 2022):

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

This happens here as well. WSL 2, Ubuntu22.04, Windows Terminal Version: 1.13.11431.0. Tmux 3.2A. Closing the terminal window or detaching from tmux resolves the issue.something seems to be happening when firefox is launched for the CRA dev server.

Launching firefox directly from the Ubuntu shell does not cause the issue.

Setting the CRA start script to "start": "BROWSER=none react-scripts start prevents the browser from auto-launching, and prevents the issue.

This works for me.
The problem appears only after runs npm start

@rodrigomartin commented on GitHub (Jul 6, 2022): > > 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 > > This happens here as well. WSL 2, Ubuntu22.04, Windows Terminal Version: 1.13.11431.0. Tmux 3.2A. Closing the terminal window or detaching from tmux resolves the issue._something_ seems to be happening when firefox is launched for the CRA dev server. > > Launching firefox directly from the Ubuntu shell does not cause the issue. > > Setting the CRA start script to `"start": "BROWSER=none react-scripts start` prevents the browser from auto-launching, and prevents the issue. This works for me. The problem appears only after runs npm start

claunia commented

@mlcamilli commented on GitHub (Aug 1, 2022):

@marwan38 did upgrading fix this issue?

@mlcamilli commented on GitHub (Aug 1, 2022): @marwan38 did upgrading fix this issue?

claunia commented

2026-01-31 02:01:40 +00:00

@marwan38 commented on GitHub (Aug 2, 2022):

@marwan38 did upgrading fix this issue?

@mlcamilli It did not, anything that renders on the right side of the screen causes this issue. It was partially fixed by changing my zsh theme based on the Oh my posh recommendation above. Whenever something decides to render on the right hand side, it comes back :(. I think I am on 3.3a last time I tried.

@marwan38 commented on GitHub (Aug 2, 2022): > @marwan38 did upgrading fix this issue? @mlcamilli It did not, anything that renders on the right side of the screen causes this issue. It was partially fixed by changing my zsh theme based on the `Oh my posh` recommendation above. Whenever something decides to render on the right hand side, it comes back :(. I think I am on 3.3a last time I tried.

claunia commented

2026-01-31 02:01:40 +00:00

@robertwt7 commented on GitHub (Aug 8, 2022):

this is still happening on tmux 3.3a, with windows terminal preview and oh my zsh powerlevel10k theme

@robertwt7 commented on GitHub (Aug 8, 2022): this is still happening on tmux 3.3a, with windows terminal preview and oh my zsh powerlevel10k theme

claunia commented

2026-01-31 02:01:41 +00:00

@ghshephard commented on GitHub (Sep 8, 2022):

Microsoft Terminal latest (1.14.2281.0) and tmux latest (3.4) - same issue. I can trigger it with something as trivial as an empty tmux.conf and "\h \u $" PS1 - doing a single horizontal split breaks tmux.

@ghshephard commented on GitHub (Sep 8, 2022): Microsoft Terminal latest (1.14.2281.0) and tmux latest (3.4) - same issue. I can trigger it with something as trivial as an empty tmux.conf and "\h \u $" PS1 - doing a single horizontal split breaks tmux. ![tmux_screen_distortion](https://user-images.githubusercontent.com/1934643/189222864-0255a827-a8a3-4625-b444-b31105de0be9.gif)

claunia commented

2026-01-31 02:01:41 +00:00

@ghshephard commented on GitHub (Sep 8, 2022):

I have a fix for my issue - disable Windows Scrollback in Ubuntu Terminal - works fine now.

@ghshephard commented on GitHub (Sep 8, 2022): I have a fix for my issue - disable Windows Scrollback in Ubuntu Terminal - works fine now. ![tmux_screen_no-scrollback-working](https://user-images.githubusercontent.com/1934643/189226936-c1032a4c-4e3e-429f-8084-b2426c0b4f9c.gif)

claunia commented

2026-01-31 02:01:42 +00:00

@scallister commented on GitHub (Sep 9, 2022):

If it's now reproducible and you have a fix for it, that gives me hope that this can finally be resolved 🤔. Good find @ghshephard! 😃

@scallister commented on GitHub (Sep 9, 2022): If it's now reproducible and you have a fix for it, that gives me hope that this can finally be resolved 🤔. Good find @ghshephard! 😃

claunia commented

2026-01-31 02:01:43 +00:00

@Gee19 commented on GitHub (Sep 9, 2022):

@ghshephard Do you have more information on how to disable the setting you mentioned?

@Gee19 commented on GitHub (Sep 9, 2022): @ghshephard Do you have more information on how to disable the setting you mentioned?

claunia commented

2026-01-31 02:01:44 +00:00

@ghshephard commented on GitHub (Sep 9, 2022):

You can disable your scrollback under Settings/Ubuntu/Advanced/History Size. Note that despite running really well for an hour or two, I eventually managed to confuse things so that we started seeing issues again. So, this is a fix for many, but not all cases.

@ghshephard commented on GitHub (Sep 9, 2022): You can disable your scrollback under Settings/Ubuntu/Advanced/History Size. Note that despite running really well for an hour or two, I eventually managed to confuse things so that we started seeing issues again. So, this is a fix for many, but not all cases.

claunia commented

2026-01-31 02:01:44 +00:00

@sobanieca commented on GitHub (Sep 24, 2022):

I'm facing similar issue with tmux. What I've noticed is that it starts to occur when I run some script via npm in other tab

It's very irritating and blocks me from using terminal+tmux+vim. Actually, not only vim is affected, I've issues with tmux scroll as well, so I'm not suspecting it's a vim issue. My assumption is that npm prints some special character that breaks all other things. Are there any logs I can gather to help troubleshoot this issue?

Npm packages used:

create-react-app link
storybook link

@sobanieca commented on GitHub (Sep 24, 2022): I'm facing similar issue with tmux. What I've noticed is that it starts to occur when I run some script via npm in other tab ![artifacts](https://user-images.githubusercontent.com/2606245/192099001-15ef63e2-a654-4e8e-871d-543df44a1308.gif) It's very irritating and blocks me from using terminal+tmux+vim. Actually, not only vim is affected, I've issues with tmux scroll as well, so I'm not suspecting it's a vim issue. My assumption is that npm prints some special character that breaks all other things. Are there any logs I can gather to help troubleshoot this issue? Npm packages used: * create-react-app [link](https://reactjs.org/docs/create-a-new-react-app.html#create-react-app) * storybook [link](https://storybook.js.org/docs/react/get-started/install)

claunia commented

2026-01-31 02:01:44 +00:00

@ghshephard commented on GitHub (Sep 24, 2022):

While ~70% of the issues have been fixed by disabling scrollback - I continue to see problems and corruptions - more often on my large 30" monitor - and almost always when I do a vertical split of a window into two tmux panes - Horizontal splits are rarely a problem. I have a (horrible) workaround - which is to kill the tmux-server and restart it (resurrection plugin restores all my panes/scroll back - so not the end of the world). This is definitely a windows terminal issues - I used tmux for 2+ years on a linux system - never once saw a corruption - and I see it daily on windows terminal. What I find surprising is that surely there are a lot of people who (A) use WSL, (B) used tmux, (C) use windows terminal - so there must be a lot of people experiencing this problem every day - Unless splitting a window vertically is just an uncommon thing.?

@ghshephard commented on GitHub (Sep 24, 2022): While ~70% of the issues have been fixed by disabling scrollback - I continue to see problems and corruptions - more often on my large 30" monitor - and almost always when I do a vertical split of a window into two tmux panes - Horizontal splits are rarely a problem. I have a (horrible) workaround - which is to kill the tmux-server and restart it (resurrection plugin restores all my panes/scroll back - so not the end of the world). This is definitely a windows terminal issues - I used tmux for 2+ years on a linux system - never once saw a corruption - and I see it daily on windows terminal. What I find surprising is that surely there are a lot of people who (A) use WSL, (B) used tmux, (C) use windows terminal - so there must be a lot of people experiencing this problem every day - Unless splitting a window vertically is just an uncommon thing.?

claunia commented

2026-01-31 02:01:45 +00:00

@chrisl8 commented on GitHub (Sep 24, 2022):

@ghshephard Same. I have used PuTTY and whatever desktop terminal program came with Linux since the 90's, using screen and later tmux, and I've always used vertical splits as part of my daily routine. I've never seen this issue in any other terminal or SSH program. That includes using sh, csh, bash, and zsh, with every kind of fancy font setup.

I'm in my second year of using WSL 2 as my daily driver and I only cope by just having entirely changed my habits. I don't use vertical splits anymore because they NEVER work. At least once a week I try it by accident out of habit, and it always immediately fails. (I should change/delete the vertical split shortcut in my tmux conf file, but I'm stubbornly hoping it will work someday.)

It is shocking to me that this is such an issue, because this is a solved problem. Terminal emulators have had zero issue with this on Linux and Mac for decades, and other Windows terminal emulators like PuTTY have no issue with it. I've never built a terminal emulator before though so I can't really judge why this is such a difficult problem to solve, despite being solved already in many other places.

This is of of the things that I'm waiting to be fixed before I can tell my Linux and Mac friends to try out Windows.

I think the reality is that most Linux power users avoid Windows, and this is one of the things that they would point to as their reason.

Let me close by saying, let me know if there is anything I can do to help. I would love to provide logs or test any ideas anyone has. I really do love and appreciate how the Windows Terminal team is being so open about their process, accepting and responding to bug reports, and making release notes. It is the reason I am a WSL 2 user. My criticism here is out of love, not because I don't respect and admire the work being done here.

@chrisl8 commented on GitHub (Sep 24, 2022): @ghshephard Same. I have used PuTTY and whatever desktop terminal program came with Linux since the 90's, using screen and later tmux, and I've always used vertical splits as part of my daily routine. I've **never** seen this issue in any other terminal or SSH program. That includes using sh, csh, bash, and zsh, with every kind of fancy font setup. I'm in my second year of using WSL 2 as my daily driver and I only cope by just having entirely changed my habits. I don't use vertical splits anymore because they NEVER work. At least once a week I try it by accident out of habit, and it always immediately fails. (I should change/delete the vertical split shortcut in my tmux conf file, but I'm stubbornly hoping it will work someday.) It is shocking to me that this is such an issue, because this is a solved problem. Terminal emulators have had zero issue with this on Linux and Mac for decades, and other Windows terminal emulators like PuTTY have no issue with it. I've never built a terminal emulator before though so I can't really judge why this is such a difficult problem to solve, despite being solved already in many other places. This is of of the things that I'm waiting to be fixed before I can tell my Linux and Mac friends to try out Windows. I think the reality is that most Linux power users avoid Windows, and this is one of the things that they would point to as their reason. Let me close by saying, let me know if there is anything I can do to help. I would love to provide logs or test any ideas anyone has. I really do love and appreciate how the Windows Terminal team is being so open about their process, accepting and responding to bug reports, and making release notes. It is the reason I am a WSL 2 user. My criticism here is out of love, not because I don't respect and admire the work being done here.

claunia commented

2026-01-31 02:01:45 +00:00

@ghshephard commented on GitHub (Sep 25, 2022):

+1 on PuTTY working flawlessly. I worked on site in Dubai for a summer back in 2013 - and had to use a jump host via RDP on windows into a linux (RedHat) server farm. 6-8 hours days for several months using tmux in that combination and there was never a hiccup. I'm right with you that WSL / Windows Terminal are, 99.9% of the time, an absolutely wonderful combination, incredibly performant (particularly when you are pasting several 10s of thousand of lines) and responsive, and if we could only resolve this one issue - it would be perfection in my books. I'm also ready to sign up to work with the developers to capture debug logs, (though hopefully my test above with scroll backs is reproducible - and might offer some guidance), beta-test, whatever is required to help run this down - particularly as I now spend 8-10 hours/day in WSL/Windows Terminal/Tmux - I have some significant skin in this game.

@ghshephard commented on GitHub (Sep 25, 2022): +1 on PuTTY working flawlessly. I worked on site in Dubai for a summer back in 2013 - and had to use a jump host via RDP on windows into a linux (RedHat) server farm. 6-8 hours days for several months using tmux in that combination and there was never a hiccup. I'm right with you that WSL / Windows Terminal are, 99.9% of the time, an absolutely wonderful combination, incredibly performant (particularly when you are pasting several 10s of thousand of lines) and responsive, and if we could only resolve this one issue - it would be perfection in my books. I'm also ready to sign up to work with the developers to capture debug logs, (though hopefully my test above with scroll backs is reproducible - and might offer some guidance), beta-test, whatever is required to help run this down - particularly as I now spend 8-10 hours/day in WSL/Windows Terminal/Tmux - I have some significant skin in this game.

claunia commented

2026-01-31 02:01:45 +00:00

@davidKristiansen commented on GitHub (Sep 26, 2022):

I found a weird workaround that works for me.

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

@davidKristiansen commented on GitHub (Sep 26, 2022): 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

claunia commented

@maxbane commented on GitHub (Sep 26, 2022):

I'm sorry to say, but this bug was such a deal-breaker that it prodded me to investigate alternative terminal emulators for Windows (others have already mentioned PuTTY, of course). I found Alacritty and have since moved all of my WSL workflows over to it rather than Windows Terminal. I highly recommend it -- it's GPU-accelerated and very configurable with a single YAML config file -- you can tweak arbitrary keybindings and even visual minutiae like how many pixels the window borders use, very nice if you have a tiling setup. And of course you can use your daily driver programs like tmux and vim without fear of corrupting the display and having to restart your terminal every 10 minutes lolol.

It's been, what, like 2 years? Time to move on.

@maxbane commented on GitHub (Sep 26, 2022): I'm sorry to say, but this bug was such a deal-breaker that it prodded me to investigate alternative terminal emulators for Windows (others have already mentioned PuTTY, of course). I found [Alacritty](https://github.com/alacritty/alacritty) and have since moved all of my WSL workflows over to it rather than Windows Terminal. I highly recommend it -- it's GPU-accelerated and very configurable with a single YAML config file -- you can tweak arbitrary keybindings and even visual minutiae like how many pixels the window borders use, very nice if you have a tiling setup. And of course you can use your daily driver programs like tmux and vim without fear of corrupting the display and having to restart your terminal every 10 minutes lolol. It's been, what, like 2 years? Time to move on.

claunia commented

@agilesteel commented on GitHub (Sep 26, 2022):

@maxbane yeah I'm also on Alacritty, just wish it had ligatures, stylistic sets and custom backgrounds.

@agilesteel commented on GitHub (Sep 26, 2022): @maxbane yeah I'm also on Alacritty, just wish it had ligatures, stylistic sets and custom backgrounds.

claunia commented

@itachi-19 commented on GitHub (Sep 26, 2022):

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

This works!!! Thanks a lot. :)

@itachi-19 commented on GitHub (Sep 26, 2022): > 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 This works!!! Thanks a lot. :)

claunia commented

@oieeaaaa commented on GitHub (Oct 15, 2022):

thanks @maxbane for recommending alacritty... I'm gonna check it out. I love using tmux but ever since i moved to WSL this has been a recurring issue to me and i dont seem to find a good solution so...

@oieeaaaa commented on GitHub (Oct 15, 2022): thanks @maxbane for recommending alacritty... I'm gonna check it out. I love using tmux but ever since i moved to WSL this has been a recurring issue to me and i dont seem to find a good solution so...

claunia commented

@jcherven commented on GitHub (Oct 15, 2022):

I was also finding refuge in Alacritty (have been a very happy user of it on Linux and MacOS for years) but in Windows Alacritty still has problems dealing with the system clipboard and NeoVim mouse events (https://github.com/alacritty/alacritty/issues/1663). These days to mitigate the bug in question I just have to run my Nodejs servers in a separate WT tab without Tmux.

I don't feel that a "great" terminal emulator should have this problem, but I have to use it this way at work and consider it just another Windows UX hazard that breaks the Unix immersion of using WSL interactively.

@jcherven commented on GitHub (Oct 15, 2022): I was also finding refuge in Alacritty (have been a very happy user of it on Linux and MacOS for years) but in Windows Alacritty still has problems dealing with the system clipboard and NeoVim mouse events (https://github.com/alacritty/alacritty/issues/1663). These days to mitigate the bug in question I just have to run my Nodejs servers in a separate WT tab without Tmux. I don't feel that a "great" terminal emulator should have this problem, but I have to use it this way at work and consider it just another Windows UX hazard that breaks the Unix immersion of using WSL interactively.

claunia commented

@agilesteel commented on GitHub (Oct 15, 2022):

For those of you who use byobu - a tmux wrapper maybe hitting F5 - refresh will help.

@agilesteel commented on GitHub (Oct 15, 2022): For those of you who use `byobu` - a tmux wrapper maybe hitting `F5` - refresh will help.

claunia commented

@maxbane commented on GitHub (Oct 17, 2022):

@jcherven Fair point about mouse support, although the issue you linked seems to have multiple people indicating that it's fixed in Windows 11. I've also heard good things about wezterm in Windows, though haven't yet tried it myself.

@maxbane commented on GitHub (Oct 17, 2022): @jcherven Fair point about mouse support, although the issue you linked seems to have multiple people indicating that it's fixed in Windows 11. I've also heard good things about [wezterm](https://wezfurlong.org/wezterm/) in Windows, though haven't yet tried it myself.

claunia commented

@dhensen commented on GitHub (Nov 4, 2022):

I have this same issue on WSL2. Opening a new terminal tab and attaching to tmux does not help.
Alacritty on windows still gives problems. No it's not related to npm packages, there are days where no js/ts code is being touched, but python, still the same issue. I don't want to give up on my setup: tmux + nvim, but I'm losing it slowly.

What else could it be? I'm on tmux 3.0a (ubuntu 20.04 LTS WSL2)

Not a pane in sight (on this window) but lots of panes open in other windows.

@dhensen commented on GitHub (Nov 4, 2022): I have this same issue on WSL2. Opening a new terminal tab and attaching to tmux does not help. Alacritty on windows still gives problems. No it's not related to npm packages, there are days where no js/ts code is being touched, but python, still the same issue. I don't want to give up on my setup: tmux + nvim, but I'm losing it slowly. What else could it be? I'm on tmux 3.0a (ubuntu 20.04 LTS WSL2) ![image](https://user-images.githubusercontent.com/2786295/200029233-26037073-837a-47b6-8c31-2202a65ddb74.png) Not a pane in sight (on this window) but lots of panes open in other windows.

claunia commented

@dhensen commented on GitHub (Nov 4, 2022):

Oh I forgot to mention. I use two tmux sessions, where they share the windows. So I can have two alacritty terminals full screen on two monitors. The right monitor will have my testrunner window on all the time. I have a case where the alacritty+tmux on the left is OK and the one on the right on the same window is not. Hard to explain, but here is a screenshot:

(I have put both terminal windows on one desktop to make the screenshot. you just have to believe that what you are looking at are two tmux sessions that share windows and are visually supposed to be in sync. When putting them both on one monitor, the left now also has weird gaps...)

@dhensen commented on GitHub (Nov 4, 2022): Oh I forgot to mention. I use two tmux sessions, where they share the windows. So I can have two alacritty terminals full screen on two monitors. The right monitor will have my testrunner window on all the time. I have a case where the alacritty+tmux on the left is OK and the one on the right on the same window is not. Hard to explain, but here is a screenshot: ![image](https://user-images.githubusercontent.com/2786295/200029903-6d90445e-9012-448f-93b8-df66eb3cf1c6.png) (I have put both terminal windows on one desktop to make the screenshot. you just have to believe that what you are looking at are two tmux sessions that share windows and are visually supposed to be in sync. When putting them both on one monitor, the left now also has weird gaps...)

claunia commented

@mlcamilli commented on GitHub (Jan 3, 2023):

for whoever this helps, I had no luck with any version or even with alacritty, HOWEVER recently came across WezTerm https://wezfurlong.org/wezterm/install/windows.html and it has worked like a charm. Very easy to setup and configure, and no rendering issues.

@mlcamilli commented on GitHub (Jan 3, 2023): for whoever this helps, I had no luck with any version or even with alacritty, HOWEVER recently came across WezTerm https://wezfurlong.org/wezterm/install/windows.html and it has worked like a charm. Very easy to setup and configure, and no rendering issues.

claunia commented

@theanuragshukla commented on GitHub (Jan 7, 2023):

If Anyone is still having this issue, try installing Windows Terminal Preview from the microsoft store. Hopefully this issue will be resolved in upcoming versions of Terminal.

@theanuragshukla commented on GitHub (Jan 7, 2023): If Anyone is still having this issue, try installing Windows Terminal Preview from the microsoft store. Hopefully this issue will be resolved in upcoming versions of Terminal.

claunia commented

@avamsi commented on GitHub (Jan 13, 2023):

^ Can confirm I don't have this issue anymore with the Preview version 1.16.3460.0, thanks @theanuragshukla!

@avamsi commented on GitHub (Jan 13, 2023): ^ Can confirm I don't have this issue anymore with the Preview version 1.16.3460.0, thanks @theanuragshukla!

claunia commented

https://github.com/microsoft/terminal/compare/v1.15.3465.0...v1.16.3463.0

@zadjii-msft commented on GitHub (Jan 13, 2023):

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.

Maybe:

Theme change does not apply properly to settings UI (#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 https://github.com/microsoft/terminal/issues/6987#issuecomment-917256763 is still broken in 1.17, so 🤷

@zadjii-msft commented on GitHub (Jan 13, 2023): 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. https://github.com/microsoft/terminal/compare/v1.15.3465.0...v1.16.3463.0 Maybe: * #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 https://github.com/microsoft/terminal/issues/6987#issuecomment-917256763 is still broken in 1.17, so 🤷

claunia commented

@avamsi commented on GitHub (Jan 14, 2023):

Yeah, it wasn't the Preview (unfortunately) but as someone else mentioned above, seems like just connecting from another client (which happened to be Preview) that "fixed" the issue for me.

@avamsi commented on GitHub (Jan 14, 2023): Yeah, it wasn't the Preview (unfortunately) but as someone else mentioned above, seems like just connecting from another client (which happened to be Preview) that "fixed" the issue for me.

claunia commented

@ryuheechul commented on GitHub (Jan 21, 2023):

I found a weird workaround that works for me.

opening tmux with a split in one Terminal tab. Here I see the rendering error.

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:

detach from tmux (and quits the terminal as well)
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).

@ryuheechul commented on GitHub (Jan 21, 2023): > 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](https://github.com/ryuheechul/dotfiles/blob/557129ee503453aa12b308abe53b88aa1d413667/alacritty/win.yml#L50) which [attaches to tmux](https://github.com/ryuheechul/dotfiles/blob/master/bin/tmux-attach-or-new.sh) when launched - [via alias](https://github.com/ryuheechul/dotfiles/blob/557129ee503453aa12b308abe53b88aa1d413667/zsh/aliases#L24) - 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](https://github.com/starship/starship) via [toggleterm in neovim](https://github.com/akinsho/toggleterm.nvim) 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](https://github.com/akinsho/toggleterm.nvim) (possibly because Zellij doesn't support passthrough yet).

claunia commented

https://user-images.githubusercontent.com/15231996/218722034-0c694b06-9045-4fde-b6c4-fe1852b544da.mp4

@jradam commented on GitHub (Feb 14, 2023):

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:

@jradam commented on GitHub (Feb 14, 2023): 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: https://user-images.githubusercontent.com/15231996/218722034-0c694b06-9045-4fde-b6c4-fe1852b544da.mp4

claunia commented

@j4james commented on GitHub (Feb 14, 2023):

@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.

@j4james commented on GitHub (Feb 14, 2023): @jradam If you can reproduce the issue easily, it would be helpful if you could record your vim session using the Linux [script](https://github.com/microsoft/terminal/wiki/Toubleshooting-Tips#script) command, and then we can see exactly what it's doing that is triggering the problem.

claunia commented

https://user-images.githubusercontent.com/15231996/218750818-d7e8460e-63ee-466b-b5ed-daaf7daf48a6.mp4

@jradam commented on GitHub (Feb 14, 2023):

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

typescript.zip

@jradam commented on GitHub (Feb 14, 2023): @j4james sure thing. Here is a video of a working terminal window becoming "corrupted", as well as the script as requested. https://user-images.githubusercontent.com/15231996/218750818-d7e8460e-63ee-466b-b5ed-daaf7daf48a6.mp4 [typescript.zip](https://github.com/microsoft/terminal/files/10732751/typescript.zip)

claunia commented

@j4james commented on GitHub (Feb 16, 2023):

@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.

@j4james commented on GitHub (Feb 16, 2023): @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.

claunia commented

https://user-images.githubusercontent.com/15231996/219384355-3f2a2bc0-2bc4-4a79-b964-5a63035bc2dc.mp4

@jradam commented on GitHub (Feb 16, 2023):

@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

@jradam commented on GitHub (Feb 16, 2023): @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](https://github.com/microsoft/terminal/files/10756678/typescript-files.zip) https://user-images.githubusercontent.com/15231996/219384355-3f2a2bc0-2bc4-4a79-b964-5a63035bc2dc.mp4

claunia commented

@j4james commented on GitHub (Feb 16, 2023):

@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.

@j4james commented on GitHub (Feb 16, 2023): @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.

claunia commented

@jradam commented on GitHub (Feb 17, 2023):

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

@jradam commented on GitHub (Feb 17, 2023): @j4james great! Hopefully that will sort it. Thanks James, looking forward to the next release then.

claunia commented