-
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
Consolidate the interfaces for setting VT input modes #11384
Conversation
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.
auto& terminalInput = _io.GetActiveInputBuffer()->GetTerminalInput(); | ||
terminalInput.SetInputMode(mode, enabled); |
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.
Why did the old code use ServiceLocator::LocateGlobals()
for this?
I'm assuming that was just some code cruft / accidental roundaboutness?
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.
Well the original code was calling through to static functions in getset.cpp which aren't part of the ConhostInternalGetSet
class, and so the only way they can access that state was through ServiceLocator::LocateGlobals
. I think this was originally because the code in getset.cpp was mostly implementations of the public console APIs, and the same pattern was followed when private functions were added. This has resulted in a fair amount of unnecessary boilerplate code, which I'm hoping we can cut down on over time.
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.
"It seemed like a good idea at the time" is the only excuse I have for this...
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.
boilerplate
cut down over time
YES PLEASE
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.
Awesome stuff. I love it.
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.
Minor questions -- I'm not blocking signoff/merge if Michael wants to, but am generally curious. Excellent work as always!
auto& terminalInput = _io.GetActiveInputBuffer()->GetTerminalInput(); | ||
terminalInput.SetInputMode(mode, enabled); |
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.
boilerplate
cut down over time
YES PLEASE
} | ||
|
||
else |
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 change will make us respond to a request for URXVT encoding by emitting Standard/X11, right?
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'm not sure - since that's not in the Mode enum, we might just always return false before we even get here. I don't think we ever actually supported that mode - I probably put it in the enum pre-emptively.
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.
Yeah, we never supported the ability to select Urxvt mode, so nothing has changed here. If you try to select that mode, it'll be ignored as an unrecognised mode in the AdaptDispatch
class.
@@ -655,7 +662,7 @@ bool TerminalInput::HandleKey(const IInputEvent* const pInEvent) | |||
// Check any other key mappings (like those for the F1-F12 keys). | |||
// These mappings will kick in no matter which modifiers are pressed and as such | |||
// must be checked last, or otherwise we'd override more complex key combinations. | |||
const auto mapping = _getKeyMapping(keyEvent, _ansiMode, _cursorApplicationMode, _keypadApplicationMode); | |||
const auto mapping = _getKeyMapping(keyEvent, _inputMode.test(Mode::Ansi), _inputMode.test(Mode::CursorKey), _inputMode.test(Mode::Keypad)); |
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.
a followup may be to consolidate the signature of _getKeyMapping to take an input mode enumset?
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.
Yeah, that would be much better - I'm sorry I didn't spot that now. There are definitely more things I'd like to do with the input at some point, so I'm sure I'll get back to this at some point if nobody else does.
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.
it's just... so much better 😍
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 (
|
🎉 Handy links: |
Instead of having a separate method for setting each mouse and keyboard
mode, this PR consolidates them all into a single method which takes a
mode parameter, and stores the modes in a
til::enumset
rather thanhaving a separate
bool
for each mode.This enables us to get rid of a lot of boilerplate code, and makes the
code easier to extend when we want to introduce additional modes in the
future. It'll also makes it easier to read back the state of the various
modes when implementing the
DECRQM
query.Most of the complication is in the
TerminalInput
class, which had tobe adjusted to work with an
enumset
in place of all thebool
fields.For the rest, it was largely a matter of replacing calls to all the old
mode setting methods with the new
SetInputMode
method, and deleting abunch of unused code.
One thing worth mentioning is that the
AdaptDispatch
implementationused to have a
_ShouldPassThroughInputModeChange
method that wascalled after every mode change. This code has now been moved up into the
SetInputMode
implementation inConhostInternalGetSet
so it's justhandled in one place. Keeping this out of the dispatch class will also
be beneficial for sharing the implementation with
TerminalDispatch
.Validation
The updated interface necessitated some adjustments to the tests in
AdapterTest
andMouseInputTest
, but the essential structure of thetests remains unchanged, and everything still passes.
I've also tested the keyboard and mouse modes in Vttest and confirmed
they still work at least as well as they did before (both conhost and
Windows Terminal), and I tested the alternate scroll mode manually
(conhost only).
Simplifying the
ConGetSet
andITerminalApi
is also part of the planto de-duplicate the
AdaptDispatch
andTerminalDispatch
implementation (#3849).