wsl vim is horribly broken after #5181 #5291
Assignees
Labels
Area-Output
Related to output processing (inserting text into buffer, retrieving buffer text, etc.)
Issue-Bug
It either shouldn't be doing this or needs an investigation.
Priority-0
Bugs that we consider release-blocking/recall-class (P0)
Product-Conpty
For console issues specifically related to conpty
Resolution-Fix-Committed
Fix is checked in, but it might be 3-4 weeks until a release.
Severity-Blocking
We won't ship a release like this! No-siree.
Milestone
Comments
DHowett-MSFT
added
Product-Conpty
ghost
added
the
Needs-Triage
|
looking now |
zadjii-msft
added a commit
that referenced
this issue
Apr 9, 2020
3 tasks
DHowett-MSFT
removed
the
Needs-Triage
ghost
added
Resolution-Fix-Committed
ghost
pushed a commit
that referenced
this issue
Apr 15, 2020
## Summary of the Pull Request When WSL vim prints the initial empty buffer (the one that's just a bunch of '\~'s), it prints this by doing the following: * Print '\~' followed by enough spaces to clear the line * Use CUP (`^[[H`) to move the cursor to the start of the next line * repeat until the buffer is full When we'd get the line of "\~ "... in conhost, we'd mark that line as wrapped. Logically, it doesn't really make any sense that when we follow that up by moving the cursor, the line is wrapped. However, this is just how conhost is right now. This wasn't ever a problem in just conhost before, because we really didn't care if lines in the alt buffer were "wrapped" or not. Plus, when vim would get resized, it would just reprint it's own buffer anyways. Nor was this a problem in conpty before this year (2020). We've only just recently added logic to conpty to try and preserve wrapped lines. Initially, I tried fixing this by breaking the line manually when the cursor was moved. This seemed to work great, except for the win32 vim.exe. Vim.exe doesn't emit a newline or a CUP to get to the next line. It just _goes for it_ and keeps printing. So there's _no way_ for us to know the line broke, because they're essentially just printing one long line, assuming we'll automatically move the cursor. So instead, I'm making sure to emit the proper number of spaces at the end of a line when the line is wrapped. We won't do any funny business in that scenario and try to optimize for them, we'll _just print the spaces_. ## References * #5181 - This change regressed this * #4415 - Actually implemented wrapped lines in conpty ## PR Checklist * [x] Closes #5291 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Validation Steps Performed * Wrote a unittest first and foremost * Checked vtpipeterm to make sure vim still works * checked Terminal to make sure vim still works
5 tasks
|
🎉This issue was addressed in #5294, which has now been successfully released as Handy links: |
This issue was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
tap output:
no cursor movement after the EL :/
The text was updated successfully, but these errors were encountered: