-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Add support for DECARM (Auto Repeat Mode) #13981
Conversation
til::enumset<Mode> _inputMode{ Mode::Ansi }; | ||
WORD _lastVirtualKeyCode{ 0 }; | ||
|
||
til::enumset<Mode> _inputMode{ Mode::Ansi, Mode::AutoRepeat }; |
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.
Is this another instance where Terminal can receive a reset/state toggle for DECARM
and end up in a torn state ala #13968?
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.
I don't think so. In the DECAC1
case we needed Terminal to have the mode permanently enabled, but that's not the case here. We're always passing through the input modes, so Terminal should always be in sync with conhost.
The other thing is that Terminal would assumedly be using Win32InputMode most of the time, so the auto repeat option would typically not have any effect on that side.
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.
This is clever, and i like that it only applies in ENABLE_VIRTUAL_TERMINAL_INPUT
mode 😄
Hello @DHowett! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
The way `DECARM` was initially implemented, we checked for repeated key presses by matching the last recorded virtual key code, and used a 0 key code to indicate that no key was pressed. This caused the VT query responses to fail, because they generated key events with a 0 key code, and that would end up being detected as a repeated key that should be suppressed. This PR fixes that issue by using a `std::optional` to track the last key code, so if no key has been pressed we can represent that with `std::nullopt`, and there's no way that can be confused with a genuine key press. The `DECARM` mode was introduced in PR #13981. ## Validation Steps Performed I've manually tested in Vttest to confirm that the query reports are now working again, even when `DECARM` is disabled. I've also checked that `DECARM` itself it still working as expected. Closes #14208
🎉 Handy links: |
This PR adds support for the
DECARM
(Auto Repeat Mode) sequence, whichcontrols whether a keypress automatically repeats if you keep it held
down for long enough.
Note that this won't fully work in Windows Terminal until issue #8440 is
resolved.
Every time we receive a
KeyDown
event, we record the virtual key codeto track that as the last key pressed. If we receive a
KeyUp
event thematches that last key code, we reset that field. Then if the Auto Repeat
Mode is reset, and we receive a
KeyDown
event that matches the lastkey code, we simply ignore it.
Validation Steps Performed
I've manually tested the
DECARM
functionality in Vttest and confirmedthat it's working as expected. Although note that in Windows Terminal
this only applies to non-alphanumeric keys for now (e.g. Tab, BackSpace,
arrow keys, etc.)
I've also added a basic unit test that verifies that repeated key
presses are suppressed when the
DECARM
mode is disabled.Closes #13919