starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Text Doesn't Reflow Properly on Window Resize after Vim Opened and Closed #10390

New Issue
Closed
opened 2026-01-31 02:20:21 +00:00 by claunia · 16 comments
claunia commented 2026-01-31 02:20:21 +00:00
Owner
Copy Link

Originally created by @Jacob-Bishop on GitHub (Aug 30, 2020).

Environment

Windows build number: 10.0.18362.0
Windows Terminal version: 1.2.2381.0
Vim: 8.1

Steps to reproduce

  1. Open Powershell in a Windows Terminal tab.
  2. Launch Vim.
  3. Close Vim.
  4. Expand the terminal window on the right side (i.e., use the mouse to resize the window).

Expected behavior

The beginning of each "PS" prompt should be anchored to the left-hand side of the window.

Actual behavior

The second "PS" prompt wraps backward onto the first line
image

Notes

This might be a duplicate with @waf's report in #7232, although this is about resizing the terminal after vim has exited and his report was about resizing the terminal while vim was open.

Originally created by @Jacob-Bishop on GitHub (Aug 30, 2020). # Environment ```none Windows build number: 10.0.18362.0 Windows Terminal version: 1.2.2381.0 Vim: 8.1 ``` # Steps to reproduce 1. Open Powershell in a Windows Terminal tab. 2. Launch Vim. 3. Close Vim. 4. Expand the terminal window on the right side (i.e., use the mouse to resize the window). # Expected behavior The beginning of each "PS" prompt should be anchored to the left-hand side of the window. # Actual behavior The second "PS" prompt wraps backward onto the first line ![image](https://user-images.githubusercontent.com/37914376/91649445-298ebb00-ea29-11ea-85c1-829c003abb1b.png) # Notes This might be a duplicate with @waf's report in #7232, although this is about resizing the terminal after vim has exited and his report was about resizing the terminal while vim was open.
claunia added the Resolution-Duplicate label 2026-01-31 02:20:21 +00:00
claunia commented 2026-01-31 02:20:21 +00:00
Author
Owner
Copy Link

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

Is this vim.exe, or a vim from a wsl distro?

@zadjii-msft commented on GitHub (Aug 30, 2020): Is this vim.exe, or a vim from a wsl distro?
claunia commented 2026-01-31 02:20:22 +00:00
Author
Owner
Copy Link

@Jacob-Bishop commented on GitHub (Aug 30, 2020):

Sorry, vim.exe.

@Jacob-Bishop commented on GitHub (Aug 30, 2020): Sorry, vim.exe.
claunia commented 2026-01-31 02:20:22 +00:00
Author
Owner
Copy Link

@elhannah commented on GitHub (Aug 30, 2020):

I have similar and I think "same" problem. When I open an Ubuntu tab in Windows Terminal, unless the terminal is exactly 50 lines and 140 columns, vim draws screen incorrectly (it's seemingly clear that vim thinks the dimensions are as above, 50x140).

I can provide some debugging information that can help re-create. If you use the "tput lines" and "tput cols" command, the window should print correspondingly the number of lines and columns:

elhannah@office-win10:/mnt/c/Users/elhan$ tput lines
50
elhannah@office-win10:/mnt/c/Users/elhan$ tput cols
140

After resizing with mouse, the window correctly reports the new sizes:

elhannah@office-win10:/mnt/c/Users/elhan$ tput lines
38
elhannah@office-win10:/mnt/c/Users/elhan$ tput cols
102

Now, if you execute "vim", the screen looks something like:

image

and after exiting (since you can't really effectively edit :-(...

lines and cols are back to the default, and no longer represent the actual lines and cols of the window.

elhannah@office-win10:/mnt/c/Users/elhan$ tput lines
50
elhannah@office-win10:/mnt/c/Users/elhan$ tput cols
140

However, what's odd, is in some cases I have been able to initiate an Ubuntu tab and after using "tput lines" and "tput cols", the screen behavior is fine and remains consistent even with window resizing. It seems once a tab is working, it continues to work fine. This so far is random to me. I've not been able to predict, nor coax a tab into good behavior, nor stop one that is working from going back to the incorrect behavior.

@elhannah commented on GitHub (Aug 30, 2020): I have similar and I think "same" problem. When I open an Ubuntu tab in Windows Terminal, unless the terminal is exactly 50 lines and 140 columns, vim draws screen incorrectly (it's seemingly clear that vim thinks the dimensions are as above, 50x140). I can provide some debugging information that can help re-create. If you use the "tput lines" and "tput cols" command, the window should print correspondingly the number of lines and columns: > elhannah@office-win10:/mnt/c/Users/elhan$ tput lines > **50** > elhannah@office-win10:/mnt/c/Users/elhan$ tput cols > **140** After resizing with mouse, the window correctly reports the new sizes: > elhannah@office-win10:/mnt/c/Users/elhan$ tput lines > **38** > elhannah@office-win10:/mnt/c/Users/elhan$ tput cols > **102** Now, if you execute "vim", the screen looks something like: ![image](https://user-images.githubusercontent.com/7785108/91669068-982a5200-ead7-11ea-8796-19ddf9fd7bf6.png) and after exiting (since you can't really effectively edit :-(... lines and cols are back to the default, and no longer represent the actual lines and cols of the window. > elhannah@office-win10:/mnt/c/Users/elhan$ tput lines > **50** > elhannah@office-win10:/mnt/c/Users/elhan$ tput cols > **140** However, what's odd, is in some cases I have been able to initiate an Ubuntu tab and after using "tput lines" and "tput cols", the screen behavior is fine and remains consistent even with window resizing. It seems once a tab is working, it continues to work fine. This so far is random to me. I've not been able to predict, nor coax a tab into good behavior, nor stop one that is working from going back to the incorrect behavior.
claunia commented 2026-01-31 02:20:22 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Sep 3, 2020):

@elhannah Is it possible you've got something like set lines=50 columns=140 in your .vimrc file? Those are options that vim uses to set the default window size, but that resizing functionality is not yet supported by Windows Terminal (see issue #5094). The problem is that conhost does actually support resizing, so the conhost backend and the Terminal frontend get out of sync, and that results in everything rendering in the wrong place.

@j4james commented on GitHub (Sep 3, 2020): @elhannah Is it possible you've got something like `set lines=50 columns=140` in your .vimrc file? Those are options that vim uses to set the default window size, but that resizing functionality is not yet supported by Windows Terminal (see issue #5094). The problem is that conhost does actually support resizing, so the conhost backend and the Terminal frontend get out of sync, and that results in everything rendering in the wrong place.
claunia commented 2026-01-31 02:20:22 +00:00
Author
Owner
Copy Link

@elhannah commented on GitHub (Sep 3, 2020):

I wondered that too, but there are no references in .vimrc.

What's odd is that in one tab I did get size working, and it behaved
perfectly as I resized. But it was not reliably reproducible.

A couple of other interesting additions to the conversation:

  1. I found that if I modified the json config file and instead of
    "source" for wsl, I changed the invoke to "commandline", much like the
    powershell configuration, and the commandline is simply the linux
    distribution of your choice. I have Ubuntu, openSUSE-42, and kali-linux,
    and they all work fine with vi when defined that way.
  2. However, :-), regardless of whether I have vi window dimensions
    correctly matching the windows terminal, I find that when I start vi, about
    10 to 25% of the time it starts in "REPLACE" mode, meaning that any
    characters I enter are going into vi as input, but vi is supposed to start
    in "normal" mode. This is easily overcome by hitting ESCAPE and continuing
    but it is confusing, and also leads me to wonder if in fact it's more than
    just a "first startup" idiosyncrasy, or if something else might be going on
    and that odd behaviors continue within the vi session.

I was happy that my configuration mod worked generally for window
dimensions and dynamic re-sizing, but I'm concerned enough about the other
issue and what is going on to continue to rely on the WSL command
window/terminal in the meantime.

Thanks for response, I will read #5094, and provide any additional feedback
if necessary.

Have a great day!

@elhannah commented on GitHub (Sep 3, 2020): I wondered that too, but there are no references in .vimrc. What's odd is that in one tab I *did* get size working, and it behaved perfectly as I resized. But it was not reliably reproducible. A couple of other interesting additions to the conversation: 1. I found that if I modified the json config file and instead of "source" for wsl, I changed the invoke to "commandline", much like the powershell configuration, and the commandline is simply the linux distribution of your choice. I have Ubuntu, openSUSE-42, and kali-linux, and they all work fine with vi when defined that way. 2. *However*, :-), regardless of whether I have vi window dimensions correctly matching the windows terminal, I find that when I start vi, about 10 to 25% of the time it starts in "REPLACE" mode, meaning that any characters I enter are going into vi as input, but vi is supposed to start in "normal" mode. This is easily overcome by hitting ESCAPE and continuing but it is confusing, and also leads me to wonder if in fact it's more than just a "first startup" idiosyncrasy, or if something else might be going on and that odd behaviors continue within the vi session. I was happy that my configuration mod worked generally for window dimensions and dynamic re-sizing, but I'm concerned enough about the other issue and what is going on to continue to rely on the WSL command window/terminal in the meantime. Thanks for response, I will read #5094, and provide any additional feedback if necessary. Have a great day!
claunia commented 2026-01-31 02:20:22 +00:00
Author
Owner
Copy Link

@elhannah commented on GitHub (Sep 3, 2020):

further clarification:

However, :-), regardless of whether I have vi window dimensions correctly

matching the windows terminal, I find that when I start vi, about 10 to 25%
of the time it starts in "REPLACE" mode, meaning that any characters I
enter are going into vi as input, but vi is supposed to start in "normal"
mode. This is easily overcome by hitting ESCAPE and continuing but it is
confusing, and also leads me to wonder if in fact it's more than just a
"first startup" idiosyncrasy, or if something else might be going on and
that odd behaviors continue within the vi session.

to enter REPLACE mode in vi, user presses SHIFT-R. So, somewhere between
initiating vi and user gaining terminal control, vi somehow thinks it's
received the "R" character.

On Thu, Sep 3, 2020 at 10:13 AM Elbert Hannah elhannah@gmail.com wrote:

I wondered that too, but there are no references in .vimrc.

What's odd is that in one tab I did get size working, and it behaved
perfectly as I resized. But it was not reliably reproducible.

A couple of other interesting additions to the conversation:

  1. I found that if I modified the json config file and instead of
    "source" for wsl, I changed the invoke to "commandline", much like the
    powershell configuration, and the commandline is simply the linux
    distribution of your choice. I have Ubuntu, openSUSE-42, and kali-linux,
    and they all work fine with vi when defined that way.
  2. However, :-), regardless of whether I have vi window dimensions
    correctly matching the windows terminal, I find that when I start vi, about
    10 to 25% of the time it starts in "REPLACE" mode, meaning that any
    characters I enter are going into vi as input, but vi is supposed to start
    in "normal" mode. This is easily overcome by hitting ESCAPE and continuing
    but it is confusing, and also leads me to wonder if in fact it's more than
    just a "first startup" idiosyncrasy, or if something else might be going on
    and that odd behaviors continue within the vi session.

I was happy that my configuration mod worked generally for window
dimensions and dynamic re-sizing, but I'm concerned enough about the other
issue and what is going on to continue to rely on the WSL command
window/terminal in the meantime.

Thanks for response, I will read #5094, and provide any additional
feedback if necessary.

Have a great day!

-E

On Wed, Sep 2, 2020 at 6:02 PM James Holderness notifications@github.com
wrote:

@elhannah https://github.com/elhannah Is it possible you've got
something like set lines=50 columns=140 in your .vimrc file? Those are
options that vim uses to set the default window size, but that resizing
functionality is not yet supported by Windows Terminal (see issue #5094
https://github.com/microsoft/terminal/issues/5094). The problem is
that conhost does actually support resizing, so the conhost backend and the
Terminal frontend get out of sync, and that results in everything rendering
in the wrong place.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/terminal/issues/7466#issuecomment-686077060,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB3MVFBHOLFUAFVYOB3ANYLSD3FJFANCNFSM4QPKWC3A
.

@elhannah commented on GitHub (Sep 3, 2020): further clarification: *However*, :-), regardless of whether I have vi window dimensions correctly > matching the windows terminal, I find that when I start vi, about 10 to 25% > of the time it *starts in "REPLACE" mode*, meaning that any characters I > enter are going into vi as input, but vi is supposed to start in "normal" > mode. This is easily overcome by hitting ESCAPE and continuing but it is > confusing, and also leads me to wonder if in fact it's more than just a > "first startup" idiosyncrasy, or if something else might be going on and > that odd behaviors continue within the vi session. to enter REPLACE mode in vi, user presses SHIFT-R. So, somewhere between initiating vi and user gaining terminal control, vi somehow thinks it's received the "R" character. On Thu, Sep 3, 2020 at 10:13 AM Elbert Hannah <elhannah@gmail.com> wrote: > I wondered that too, but there are no references in .vimrc. > > What's odd is that in one tab I *did* get size working, and it behaved > perfectly as I resized. But it was not reliably reproducible. > > A couple of other interesting additions to the conversation: > > 1. I found that if I modified the json config file and instead of > "source" for wsl, I changed the invoke to "commandline", much like the > powershell configuration, and the commandline is simply the linux > distribution of your choice. I have Ubuntu, openSUSE-42, and kali-linux, > and they all work fine with vi when defined that way. > 2. *However*, :-), regardless of whether I have vi window dimensions > correctly matching the windows terminal, I find that when I start vi, about > 10 to 25% of the time it starts in "REPLACE" mode, meaning that any > characters I enter are going into vi as input, but vi is supposed to start > in "normal" mode. This is easily overcome by hitting ESCAPE and continuing > but it is confusing, and also leads me to wonder if in fact it's more than > just a "first startup" idiosyncrasy, or if something else might be going on > and that odd behaviors continue within the vi session. > > I was happy that my configuration mod worked generally for window > dimensions and dynamic re-sizing, but I'm concerned enough about the other > issue and what is going on to continue to rely on the WSL command > window/terminal in the meantime. > > Thanks for response, I will read #5094, and provide any additional > feedback if necessary. > > Have a great day! > > -E > > On Wed, Sep 2, 2020 at 6:02 PM James Holderness <notifications@github.com> > wrote: > >> @elhannah <https://github.com/elhannah> Is it possible you've got >> something like set lines=50 columns=140 in your .vimrc file? Those are >> options that vim uses to set the default window size, but that resizing >> functionality is not yet supported by Windows Terminal (see issue #5094 >> <https://github.com/microsoft/terminal/issues/5094>). The problem is >> that conhost does actually support resizing, so the conhost backend and the >> Terminal frontend get out of sync, and that results in everything rendering >> in the wrong place. >> >> — >> You are receiving this because you were mentioned. >> Reply to this email directly, view it on GitHub >> <https://github.com/microsoft/terminal/issues/7466#issuecomment-686077060>, >> or unsubscribe >> <https://github.com/notifications/unsubscribe-auth/AB3MVFBHOLFUAFVYOB3ANYLSD3FJFANCNFSM4QPKWC3A> >> . >> >
claunia commented 2026-01-31 02:20:22 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Sep 3, 2020):

The REPLACE mode problem is probably issue #1637. One theory is that it's got something to do with vim sending a cursor position requestion, for which the response is an escape sequence ending with R. If something goes wrong with the parsing of that response it may be misinterpreted as an R keypress.

@j4james commented on GitHub (Sep 3, 2020): The REPLACE mode problem is probably issue #1637. One theory is that it's got something to do with vim sending a cursor position requestion, for which the response is an escape sequence ending with `R`. If something goes wrong with the parsing of that response it may be misinterpreted as an `R` keypress.
claunia commented 2026-01-31 02:20:23 +00:00
Author
Owner
Copy Link

@Jacob-Bishop commented on GitHub (Sep 4, 2020):

@elhannah I think that might be a different problem -- I'm not seeing any problem with vim opening in replace mode, and resizing while Vim's open works fine. Maybe because I'm launching vim.exe from powershell rather than vim in an ubuntu terminal?

@Jacob-Bishop commented on GitHub (Sep 4, 2020): @elhannah I think that might be a different problem -- I'm not seeing any problem with vim opening in replace mode, and resizing while Vim's open works fine. Maybe because I'm launching vim.exe from powershell rather than vim in an ubuntu terminal?
claunia commented 2026-01-31 02:20:23 +00:00
Author
Owner
Copy Link

@elhannah commented on GitHub (Sep 4, 2020):

right, this happens from a tab running ubuntu in windows terminal.

from a powershell tab I've not been able to recreate the REPLACE mode bug.
I am invoking explicitly the vim.exe (I'm running vim 8.2).

You can see how many times I've invoked in this screen shot:

[image: image.png]

However, there is something odd with vim's behavior in the powershell
window. as I type in input mode, random placement of characters appear, it
looks like it's mostly on the same line
that I'm typing. I'll do more with this to see if I can get more specific
descriptions.

(As a side note, some of this is interesting and important to me as I'm in
the middle of writing the 8th Ed of the O'Reilly "Learning the vi and Vim
Editors
https://www.amazon.com/Learning-Vim-Editors-Processing-Maximum/dp/059652983X/ref=cm_cr_arp_d_product_top?ie=UTF8"
book. I'm trying to describe and include as much landscape as possible
where vim runs (under the heading of "vim is everywhere").)

@elhannah commented on GitHub (Sep 4, 2020): right, this happens from a tab running ubuntu in windows terminal. from a powershell tab I've not been able to recreate the REPLACE mode bug. I am invoking explicitly the vim.exe (I'm running vim 8.2). You can see how many times I've invoked in this screen shot: [image: image.png] However, there is something odd with vim's behavior in the powershell window. as I type in input mode, random placement of characters appear, it looks like it's mostly on the same line that I'm typing. I'll do more with this to see if I can get more specific descriptions. (As a side note, some of this is interesting and important to me as I'm in the middle of writing the 8th Ed of the O'Reilly "Learning the vi and Vim Editors <https://www.amazon.com/Learning-Vim-Editors-Processing-Maximum/dp/059652983X/ref=cm_cr_arp_d_product_top?ie=UTF8>" book. I'm trying to describe and include as much landscape as possible where vim runs (under the heading of "vim is everywhere").)
claunia commented 2026-01-31 02:20:24 +00:00
Author
Owner
Copy Link

@doesitblend commented on GitHub (Sep 11, 2020):

I believe I can reproduce the issue described @elhannah almost 100% in my environment.

From either a Powershell, or WSL2 tab I ssh to a remote machine, attach to a docker instance and then run vim. Before resizing the terminal, this operates normally as expected running Vim 7.4 on CentOS Linux release 7.8.2003 (Core).

I usually just maximize my terminal window with the keyboard shortcut Windows+up arrow. After resizing the terminal, every time I run vim on that Docker container I am automatically in REPLACE mode for some reason. If return the terminal to default size with Windows+down arrow, the terminal behaves normally again. I can only replicate this in Windows Terminal.

This also happens if I run a Linux VM in Hyper-V locally and SSH in to that machine. It's even worse if I run a FreeBSD VM and do the same.

This strange behavior is 100% reproducible in csh/tcsh on FreeBSD 12.1 running in a Hyper-V VM locally on the desktop. This runs Vim 8.2. No need to resize the window or anything. Just run Vim and you will start in REPLACE mode.

@doesitblend commented on GitHub (Sep 11, 2020): I believe I can reproduce the issue described @elhannah almost 100% in my environment. From either a Powershell, or WSL2 tab I ssh to a remote machine, attach to a docker instance and then run vim. Before resizing the terminal, this operates normally as expected running Vim 7.4 on CentOS Linux release 7.8.2003 (Core). I usually just maximize my terminal window with the keyboard shortcut Windows+up arrow. After resizing the terminal, every time I run vim on that Docker container I am automatically in REPLACE mode for some reason. If return the terminal to default size with Windows+down arrow, the terminal behaves normally again. I can only replicate this in Windows Terminal. This also happens if I run a Linux VM in Hyper-V locally and SSH in to that machine. It's even worse if I run a FreeBSD VM and do the same. This strange behavior is 100% reproducible in csh/tcsh on FreeBSD 12.1 running in a Hyper-V VM locally on the desktop. This runs Vim 8.2. No need to resize the window or anything. Just run Vim and you will start in REPLACE mode.
claunia commented 2026-01-31 02:20:24 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Sep 11, 2020):

The REPLACE mode issue is being tracked elsewhere (#1637) and has been fixed pending release. If you don’t mind, I would like to keep this thread on the topic of text reflow issues. Thanks!

@DHowett commented on GitHub (Sep 11, 2020): The REPLACE mode issue is being tracked elsewhere (#1637) and has been fixed pending release. If you don’t mind, I would like to keep this thread on the topic of text reflow issues. Thanks!
claunia commented 2026-01-31 02:20:24 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Oct 1, 2020):

Hey sorry for letting this go untriaged for so long - @Jacob-Bishop could you share your powershell profile? Have you done anything to your .vimrc that might change lines or columns? I can't get this to repro locally with a vim.exe v8.2 (but I'd doubt that this was changed in between those two versions)

@zadjii-msft commented on GitHub (Oct 1, 2020): Hey sorry for letting this go untriaged for so long - @Jacob-Bishop could you share your powershell profile? Have you done anything to your `.vimrc` that might change `lines` or `columns`? I can't get this to repro locally with a vim.exe v8.2 (but I'd _doubt_ that this was changed in between those two versions)
claunia commented 2026-01-31 02:20:24 +00:00
Author
Owner
Copy Link

@elhannah commented on GitHub (Oct 1, 2020):

I know you're asking Jacob, but I had the same issue, and no reference in
.vimrc to setting lines and columns.

But! The good news is I have the latest version of Terminal, and the issue
has been resolved. It seems to be working perfectly now.

Thanks.

@elhannah commented on GitHub (Oct 1, 2020): I know you're asking Jacob, but I had the same issue, and no reference in .vimrc to setting lines and columns. But! The good news is I have the latest version of Terminal, and the issue has been resolved. It seems to be working perfectly now. Thanks.
claunia commented 2026-01-31 02:20:25 +00:00
Author
Owner
Copy Link

@Jacob-Bishop commented on GitHub (Oct 3, 2020):

@zadjii-msft, thanks for looking into this:

  1. I just successfully reproduced the issue in a Command Prompt tab, so it doesn't seem to be a powershell-specific issue. I also haven't created a powershell config file. That said, I am running an old version of powershell -- 5.1.18362.752. I don't think that should matter?

  2. I just updated Vim to 8.2 (the gvim_8.2.0012_x86_signed.exe installer recommended on vim.org), and I'm still seeing the issue. I can reproduce the issue with vim --clean, so it shouldn't be related to my Vim config either.

Current Windows Terminal version is 1.3.2651.0, the latest version on the Microsoft Store.

Let me know if there is other information that would be useful.

One additional note that I don't think I mentioned originally, which may be helpful in your attempts to reproduce- lines created after exiting Vim are correctly anchored to the left side of the terminal, but lines created before opening vim are not.
image

@Jacob-Bishop commented on GitHub (Oct 3, 2020): @zadjii-msft, thanks for looking into this: 1) I just successfully reproduced the issue in a Command Prompt tab, so it doesn't seem to be a powershell-specific issue. I also haven't created a powershell config file. That said, I am running an old version of powershell -- `5.1.18362.752`. I don't think that should matter? 2) I just updated Vim to 8.2 (the `gvim_8.2.0012_x86_signed.exe` installer recommended on vim.org), and I'm still seeing the issue. I can reproduce the issue with `vim --clean`, so it shouldn't be related to my Vim config either. Current Windows Terminal version is 1.3.2651.0, the latest version on the Microsoft Store. Let me know if there is other information that would be useful. One additional note that I don't think I mentioned originally, which may be helpful in your attempts to reproduce- lines created after exiting Vim are correctly anchored to the left side of the terminal, but lines created before opening vim are not. ![image](https://user-images.githubusercontent.com/37914376/94998414-802a7000-0566-11eb-9de7-f70893cf8c56.png)
claunia commented 2026-01-31 02:20:25 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Oct 23, 2020):

So, I think that this is another instance of #3088. It's not titled correctly, but there's something that vim does when launches/exits that causes it to print out every character that was on the screen. After that happens, lines in the buffer are incorrectly marked as wrappable.

/dup #3088

@DHowett commented on GitHub (Oct 23, 2020): So, I think that this is another instance of #3088. It's not titled correctly, but there's something that vim does when launches/exits that causes it to print out _every character that was on the screen_. After that happens, lines in the buffer are incorrectly marked as wrappable. /dup #3088
claunia commented 2026-01-31 02:20:25 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Oct 23, 2020):

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

@ghost commented on GitHub (Oct 23, 2020): Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Resolution-Duplicate
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#10390
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?