Scrolling in the Alternate Screen Buffer should send up/down keystrokes? #3321
Comments
yossizahn
added
the
Issue-Feature
ghost
added
Needs-Triage
|
FYI: Konsole supports this too. In all three of these emulators, you can toggle this behavior runtime using DECSET 1007. |
zadjii-msft
added
Product-Conhost
DHowett-MSFT
removed
the
Needs-Triage
Note that there are issues with the current conhost implementation though. I just did a quick test in VIM (version 8.0.1453), and mouse wheel scrolling had no effect. There are two reasons for this:
|
|
FYI, I've submitted a PR for the |
## Summary of the Pull Request If the _Alternate Scroll Mode_ is enabled, the terminal generates up/down keystrokes when the mouse wheel is scrolled. However, the expected escape sequences for those keys are dependent on the state of the _Cursor Keys Mode_ ( `DECCKM`), but we haven't taken that into account. This PR updates the alternate scroll implementation to make sure the appropriate sequences are sent for both `DECCKM` modes. ## References #3321 ## PR Checklist * [ ] Closes #xxx * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [x] Tests added/passed * [ ] Requires documentation to be updated * [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx ## Detailed Description of the Pull Request / Additional comments I've simply added a condition in the `TerminalInput::_SendAlternateScroll` method to send a different pair of sequences dependent on the state of `_cursorApplicationMode` flag. ## Validation Steps Performed Manually tested in VIM (although that required me enabling the _Alternate Scroll Mode_ myself first). Also added a new unit test in `MouseInputTest` to confirm the correct sequences were generated for both `DECCKM` modes.
Er... I'm no console guru, so I may have not totally understood the previous discussion...
Are you sure about that? I just checked with Gnome Terminal (VTE based, I believe) and mintty. And they both behave correctly whether |
Yes, but only if you enable the alternate scrolling mode first (i.e. something like
I haven't tried Gnome Terminal, but Mintty definitely behaves weirdly for me with That said, I don't feel strongly about what this defaults too, and maybe there is a way to have it enabled by default and still work well with applications that handle the scrolling themselves. But for now at least we're compatible with XTerm, and anyone that prefers it on by default can still trigger that manually. |
|
Ruh roh, did we regress this for conhost? I'm going to do this for the Terminal branched off of #12561 and it's not even working in conhost anymore 😨 Sorry for the panic. The correct thing to do here is That enables alternate scroll mode, then runs |
_⚠️ targets #12561⚠️ _ "Alternate scroll mode" is a neat little mode where the app wants mouse wheel events to come through as arrow keypresses instead, when in the alternate buffer. Now that we've got support for the alt buffer in the Terminal, we can support this as well. * [x] Closes #3321 * [x] I work here * [ ] Tests would be nice Tested manually with ```bash printf "\e[?1007h" ; man ps ```
This PR allows the Terminal to actually use the alt buffer
appropriately. Currently, we just render the alt buffer state into the
main buffer and that is wild. It means things like `vim` will let the
user scroll up to see the previous history (which it shouldn't).
Very first thing this PR does: updates the
`{Trigger|Invalidate}Circling` methods to instead be
`{Trigger|Invalidate}Flush(bool circling)`. We need this so that when an
app requests the alt buffer in conpty, we can immediately flush the
frame before asking the Terminal side to switch to the other buffer. The
`Circling` methods was a great place to do this, but we don't actually
want to set the circled flag in VtRenderer when that happens just for a
flush.
The Terminal's implementation is a little different than conhost's.
Conhost's implementation grew organically, so I had it straight up
create an entire new screen buffer for the alt buffer. The Terminal
doesn't need all that! All we need to do is have a separate `TextBuffer`
for the alt buffer contents. This makes other parts easier as well - we
don't really need to do anything with the `_mutableViewport` in the alt
buffer, because it's always in the same place. So, we can just leave it
alone and when we come back to the main buffer, there it is. Helper
methods have been updated to account for this.
* [x] Closes #381
* [x] Closes #3492
* #3686, #3082, #3321, #3493 are all good follow-ups here.
ghost
added
Resolution-Fix-Committed
"Alternate scroll mode" is a neat little mode where the app wants mouse wheel events to come through as arrow keypresses instead, when in the alternate buffer. Now that we've got support for the alt buffer in the Terminal, we can support this as well. * [x] Closes #3321 * [x] I work here * [ ] Tests would be nice Tested manually with ```bash printf "\e[?1007h" ; man ps ```
|
This was merged in #12657, I didn't notice the two didn't get linked up. |
|
🎉This issue was addressed in #12569, which has now been successfully released as Handy links: |
Description of the new feature/enhancement
Many terminals will set different scrolling behavior within the Alternate Screen Buffer such that scrolling will send up/down key strokes. This seems to make more sense than scrolling through the main buffer's history.
xterm has this as an option (set by the 'alternatescroll' Xresource), VTE based terminals have this set as default behavior.
Please consider adding this capability to Windows Terminal.
Depends on #381.
The text was updated successfully, but these errors were encountered: