[vim/vim] Bad formatting in Windows Terminal after exiting vim and opening new pane (Issue #11706)
brobison75
Steps to reproduce
- open Windows Terminal session (default PowerShell is fine)
- run and exit vim
- open vertical pane with Ctrl-Alt-=
Pre-existing content in the left-most pane will display as if, apparently, the new terminal width remains that of the old (wide) terminal (see attached). Navigating back to the left-most pane with Alt-Left and hitting Enter shows that new content seems to display correctly (see attached).
Opening a new vertical pane without running Vim at Step 2 leaves the left page correctly displayed.
Running and exiting Nano instead at Step 2 leaves the left page correctly displayed.
This may seem like a minor issue, but I am seeing a plethora of display-garbage problems on multi-pane Windows Terminal when using Vim which makes the combination nearly unusable, and since this could be the root of all of them and is easily reproducible (I hope), it might be worth giving some priority.
Expected behaviour
Pre-existing content in left-most pane should display correctly with the line length matching the pane width.
Version of Vim
9.0.1054
Environment
Windows 10.0.19045
Windows Terminal 1.15.2874.0
Windows PowerShell 5.1.19041.2364
Logs and stack traces
No response
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christopher Plewright
I saw this also,
#11507
I tried to fix it, at least it works on Windows 11.
#11526
patch 9.0.0868: MS-Windows: after Vim exits console resizing problem
1140b51
I was worried about breaking changes in windows 10, because some existing tests stopped working when I tried to fix it there.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christopher Plewright
@brobison75 and @k-takata
It depends if the installation includes the (now aging) WinPTY. I think it falls back to the new MS built ConPTY if WinPTY is not available. And I believe that works.
The history is complicated; see for example;
https://groups.google.com/g/vim_dev/c/3kpOjOzUKNU
@brobison75, the temporary test to see if this is the cause, would be to see if you can remove the WinPTY DLL files from the Vim runtime, and make sure that there is no old WinPTY any directory referenced in PATH.
I'll try an find the commands to check its not using that. And will add another response if I find those commands.
I'm only vaguely aware of the problems you were dealing with back in 2019, that made you prefer WinPTY instead. I know that MS Windows own ConPTY has been evolving rapidly since then, and it "might" be good enough now to use as the default, and perhaps have a setting if users have any special need for the older WinPTY.
So, I'd like to suggest we make an exception for
(Win 10 22H2 Final) Windows 10 19045
Because, that seems to have the newer ConPTY fix in it.
Strange thing though, I thought I checked windows 10, build 19587, and it failed on there - now, the thing strange about that, is the fact that build 19045 is newer than 19587. So, it's not as simple as checking for CONPTY_STABLE_BUILD >= 19045.
Now, build 19587, was just "Windows 10 Insider Preview" that came out in 2020, and, as an insider build, is expected to have issues. So, maybe it is simple as saying CONPTY_STABLE_BUILD >= 19045 , and and anyone using the old insiders build should be easily run windows updates to at least get the 19045 (22H2 Final) anyway.
I asked this previously, and @brammool didn't have a specific opinion either way, I guess he just wants it to work.
If @brobison75 can test if my suggested workaround works (removing the winpty.DLL from vim directory), then I will go ahead and create a PR to see how that goes.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christopher Plewright
Just a one liner change, so created the PR anyway, and lets see if it fails any CI test scripts.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
K.Takata
I don't remember well, but I think there was an issue (or difference from Command Prompt) in handling of ambiguous-width characters. I'm not sure if it has been fixed or not (considered as a specification).
I have another concerning about ConPTY.
Vim failed into a deadlock when I ran the terminal tests with ConPTY on my PC few years ago. Not sure if it still happens.
It seems that it was the same as #11445 (closed because the OP didn't report properly).
I think we need to consider two separate things:
- Whether we can use ConPTY in the terminal feature.
- Whether we can use
ENABLE_VIRTUAL_TERMINAL_PROCESSING. How to restore the screen should be relates to this item.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christopher Plewright
Yes, actually using ConPTY is still breaking some CI tests, so I have discarded my PR for now.
It seems I misread OP issue. I mistakenly looked at the picture and thought they were using internal multiple terminal windows inside the same Vim instance. If that was the case, then ConPTY v WinPTY is involved. But, it seems not the case, because OP wrote that they did the following;
- open vertical pane with Ctrl-Alt-=
And that is not a Vim command, that is the new Windows Terminal command to open a Split Pane.
w.r.t ENABLE_VIRTUAL_TERMINAL_PROCESSING, that's right, and I think I already fixed the screen restore using the alternate screen buffer vtp sequence.
Can you you please confirm what setting you have in the Command Prompt properties "Wrap text output on resize."
I think I had an issue with this setting affecting windows terminal too.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
brobison75
Hello, and thanks for the quick response.
In a standalone Command Prompt window, "Wrap text output on resize" is indeed checked. I don't have any evidence however that changes to the profile in the standalone window carry over to the Windows Terminal environment, for example changes to the standalone background color do not propagate to the terminal-created cmd windows. In any event, the problem remains in the terminal after unchecking in the standalone, and I couldn't find a similar checkbox within Windows Terminal settings.
As expected, hiding winpty*.dll did not affect the problem either.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christopher Plewright
Sorry, I was barking up the wrong tree, wrt winpty. I was getting the two issues muddled up.
Looking again at the source code for my fix to make the Screen Restore work properly, for some reason I restricted that fix to >= Windows 11. But, I can't recall why I did that. There may have been some test failures. I will see if I can make it work for Window 10 22H2 Final (build 19045) without breaking any tests. (ie. similar to yesterdays quick PR, but this time for the screen restore issue rather than the winpty/conpty issue. :)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christopher Plewright
My patch applied to windows 10 is failing some tests related Test_popup_and_window_resize
Moving the PR to draft for now, will have more time to investigate this later.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
brobison75
@zewpo I appreciate it. FYI, I did test 9.0.0868 on Windows 11 and I confirm it is fixed there (where it is broken in 9.0.0000).
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
Closed #11706 as completed via c8b126d.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.