-
Notifications
You must be signed in to change notification settings - Fork 8.4k
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
Suggestions pop up of the Japanese MS IME got pushed down after multiple commands #13769
Comments
We may also (or instead) have mixed up a viewport -> buffer conversion. |
I'm bisecting. :)
|
I may not be able to finish bisecting just yet. Here's the current bisect log:
|
This is weird, but bisect pointed to f4e0d9f (#13024) It did remove a copy of We may need to introduce something like that again -- or propagate knowledge of the viewport offset up to (/cc @j4james) |
Oh my god, I think we were just getting unimaginably lucky the whole time?
There were two, and one of them was pulled when we were const-qualified. James' PR removed the first one. They had different return values...! |
Sorry about that. I'll try and have a look on the weekend if someone else hasn't fixed it by then. |
In #13024, we removed `Terminal::GetCursorPosition` from TerminalCore. This has been widely regarded as a good move. Now, you might rightly be wondering: why didn't compilation immediately fail? Well. It turns out that there were _two_ copies of `GetCursorPosition`. One for `const Terminal`, and one for `Terminal`. This is important. `Terminal::GetCursorPosition()` returned the cursor position relative to the viewport. `Terminal::GetCursorPosition() const`, however, returns the cursor position in absolute. We removed the non-`const` one. Fortunately, thanks to the lookup rules for `const`-qualified members, this didn't matter. Code that called `GetCursorPosition()` still called `GetCursorPosition()`, and everything was fine. Except that part about the relative coordinates. That was not fine. The TSF control is the _only_ consumer of `ControlCore.CursorPosition`, and that was the _only_ consumer of relative-`GetCursorPosition()`. This commit restores equilibrium by introducing a new `GetViewportRelativeCursorPosition()` member to `Terminal` and switching over the only consumer of relative cursor position to use it. Closes #13769.
In #13024, we removed `Terminal::GetCursorPosition` from TerminalCore. This has been widely regarded as a good move. Now, you might rightly be wondering: why didn't compilation immediately fail? Well. It turns out that there were _two_ copies of `GetCursorPosition`. One for `const Terminal`, and one for `Terminal`. This is important. `Terminal::GetCursorPosition()` returned the cursor position relative to the viewport. `Terminal::GetCursorPosition() const`, however, returns the cursor position in absolute. We removed the non-`const` one. Fortunately, thanks to the lookup rules for `const`-qualified members, this didn't matter. Code that called `GetCursorPosition()` still called `GetCursorPosition()`, and everything was fine. Except that part about the relative coordinates. That was not fine. The TSF control is the _only_ consumer of `ControlCore.CursorPosition`, and that was the _only_ consumer of relative-`GetCursorPosition()`. This commit restores equilibrium by introducing a new `GetViewportRelativeCursorPosition()` member to `Terminal` and switching over the only consumer of relative cursor position to use it. Closes #13769.
In #13024, we removed `Terminal::GetCursorPosition` from TerminalCore. This has been widely regarded as a good move. Now, you might rightly be wondering: why didn't compilation immediately fail? Well. It turns out that there were _two_ copies of `GetCursorPosition`. One for `const Terminal`, and one for `Terminal`. This is important. `Terminal::GetCursorPosition()` returned the cursor position relative to the viewport. `Terminal::GetCursorPosition() const`, however, returns the cursor position in absolute. We removed the non-`const` one. Fortunately, thanks to the lookup rules for `const`-qualified members, this didn't matter. Code that called `GetCursorPosition()` still called `GetCursorPosition()`, and everything was fine. Except that part about the relative coordinates. That was not fine. The TSF control is the _only_ consumer of `ControlCore.CursorPosition`, and that was the _only_ consumer of relative-`GetCursorPosition()`. This commit restores equilibrium by introducing a new `GetViewportRelativeCursorPosition()` member to `Terminal` and switching over the only consumer of relative cursor position to use it. Closes #13769. Backport of #13785.
In #13024, we removed `Terminal::GetCursorPosition` from TerminalCore. This has been widely regarded as a good move. Now, you might rightly be wondering: why didn't compilation immediately fail? Well. It turns out that there were _two_ copies of `GetCursorPosition`. One for `const Terminal`, and one for `Terminal`. This is important. `Terminal::GetCursorPosition()` returned the cursor position relative to the viewport. `Terminal::GetCursorPosition() const`, however, returns the cursor position in absolute. We removed the non-`const` one. Fortunately, thanks to the lookup rules for `const`-qualified members, this didn't matter. Code that called `GetCursorPosition()` still called `GetCursorPosition()`, and everything was fine. Except that part about the relative coordinates. That was not fine. The TSF control is the _only_ consumer of `ControlCore.CursorPosition`, and that was the _only_ consumer of relative-`GetCursorPosition()`. This commit restores equilibrium by introducing a new `GetViewportRelativeCursorPosition()` member to `Terminal` and switching over the only consumer of relative cursor position to use it. Closes #13769.
In #13024, we removed `Terminal::GetCursorPosition` from TerminalCore. This has been widely regarded as a good move. Now, you might rightly be wondering: why didn't compilation immediately fail? Well. It turns out that there were _two_ copies of `GetCursorPosition`. One for `const Terminal`, and one for `Terminal`. This is important. `Terminal::GetCursorPosition()` returned the cursor position relative to the viewport. `Terminal::GetCursorPosition() const`, however, returns the cursor position in absolute. We removed the non-`const` one. Fortunately, thanks to the lookup rules for `const`-qualified members, this didn't matter. Code that called `GetCursorPosition()` still called `GetCursorPosition()`, and everything was fine. Except that part about the relative coordinates. That was not fine. The TSF control is the _only_ consumer of `ControlCore.CursorPosition`, and that was the _only_ consumer of relative-`GetCursorPosition()`. This commit restores equilibrium by introducing a new `GetViewportRelativeCursorPosition()` member to `Terminal` and switching over the only consumer of relative cursor position to use it. Closes #13769. (cherry picked from commit 2dedc9a) Service-Card-Id: 85131461 Service-Version: 1.15
🎉This issue was addressed in #13785, which has now been successfully released as Handy links: |
🎉This issue was addressed in #13785, which has now been successfully released as Handy links: |
Windows Terminal version
1.15.2282.0
Windows build number
10.0.19044.1889
Other Software
No response
Steps to reproduce
Expected Behavior
this doesn't happen on v1.13.10983.0
what's being typed is shown in the input area
Actual Behavior
This happens on v1.14.1432.0 and above.
v1.15.2282.0
v1.14.1432.0
also, what's being typed isn't shown in the input area
The text was updated successfully, but these errors were encountered: