-
Notifications
You must be signed in to change notification settings - Fork 8.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Emit lines wrapped due to spaces at the end correctly #5294
Changes from all commits
f50bf15
54942c3
12018e4
f0f5b0c
238e61d
6ea74d6
297fcea
cb01398
8284bfb
1a9fa14
cebdb8f
43ea3ce
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -443,15 +443,23 @@ using namespace Microsoft::Console::Types; | |
const bool useEraseChar = (optimalToUseECH) && | ||
(!_newBottomLine) && | ||
(!_clearedAllThisFrame); | ||
const bool printingBottomLine = coord.Y == _lastViewport.BottomInclusive(); | ||
|
||
// If we're not using erase char, but we did erase all at the start of the | ||
// frame, don't add spaces at the end. | ||
// | ||
// GH#5161: Only removeSpaces when we're in the _newBottomLine state and the | ||
// line we're trying to print right now _actually is the bottom line_ | ||
const bool removeSpaces = useEraseChar || | ||
_clearedAllThisFrame || | ||
(_newBottomLine && coord.Y == _lastViewport.BottomInclusive()); | ||
// | ||
// GH#5291: DON'T remove spaces when the row wrapped. We might need those | ||
// spaces to preserve the wrap state of this line, or the cursor position. | ||
// For example, vim.exe uses "~ "... to clear the line, and then leaves | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We used to used to do something like " is the real problem that we're not putting the cursor at the end of the line, and the spaces make up for that? and suppressing the spaces would mean we move the cursor wrong? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. (I'm worried about the accidental deoptimization in not using ECH/EL, i guess.) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. if we just did the Theoretically we could do There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Fair enough. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm concerned about the efficiency of it, though. We realized a lot of gains recently simply by emitting fewer things between the PTY and the Terminal. It's a little dirtier, but it's 69 fewer bytes to send, parse, and react to. That doesn't sound like much for one line, but it could be easily magnified over multiple lines and redraws. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So here's my thought - the client app was already emitting all these spaces intentionally. This was actually an optimization that conpty was doing for them, and an optimization that we were doing wrong (in this scenario). We'll still be sending the optimized sequences if the app does something like "Y X", or if the app uses There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Alright, then I'm fine with it. Thanks. |
||
// the lines _wrapped_. It doesn't care to manually break the lines, but if | ||
// we trimmed the spaces off here, we'd print all the "~"s one after another | ||
// on the same line. | ||
const bool removeSpaces = !lineWrapped && (useEraseChar || | ||
_clearedAllThisFrame || | ||
(_newBottomLine && printingBottomLine)); | ||
const size_t cchActual = removeSpaces ? | ||
(cchLine - numSpaces) : | ||
cchLine; | ||
|
@@ -547,7 +555,7 @@ using namespace Microsoft::Console::Types; | |
RETURN_IF_FAILED(_EraseLine()); | ||
} | ||
} | ||
else if (_newBottomLine && coord.Y == _lastViewport.BottomInclusive()) | ||
else if (_newBottomLine && printingBottomLine) | ||
{ | ||
// If we're on a new line, then we don't need to erase the line. The | ||
// line is already empty. | ||
|
@@ -566,7 +574,7 @@ using namespace Microsoft::Console::Types; | |
|
||
// If we printed to the bottom line, and we previously thought that this was | ||
// a new bottom line, it certainly isn't new any longer. | ||
if (coord.Y == _lastViewport.BottomInclusive()) | ||
if (printingBottomLine) | ||
{ | ||
_newBottomLine = false; | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice warning to future us.