Skip to content
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

Merged
6 commits merged into from
Oct 26, 2021

Conversation

j4james
Copy link
Collaborator

@j4james j4james commented Sep 30, 2021

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 than
having 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 to
be adjusted to work with an enumset in place of all the bool 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 a
bunch of unused code.

One thing worth mentioning is that the AdaptDispatch implementation
used to have a _ShouldPassThroughInputModeChange method that was
called after every mode change. This code has now been moved up into the
SetInputMode implementation in ConhostInternalGetSet so it's just
handled 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 and MouseInputTest, but the essential structure of the
tests 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 and ITerminalApi is also part of the plan
to de-duplicate the AdaptDispatch and TerminalDispatch
implementation (#3849).

Copy link
Member

@lhecker lhecker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

image

rad dude

Comment on lines +251 to +252
auto& terminalInput = _io.GetActiveInputBuffer()->GetTerminalInput();
terminalInput.SetInputMode(mode, enabled);
Copy link
Member

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?

Copy link
Collaborator Author

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.

Copy link
Member

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...

Copy link
Member

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

Copy link
Member

@miniksa miniksa left a 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.

Copy link
Member

@DHowett DHowett left a 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!

Comment on lines +251 to +252
auto& terminalInput = _io.GetActiveInputBuffer()->GetTerminalInput();
terminalInput.SetInputMode(mode, enabled);
Copy link
Member

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
Copy link
Member

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?

Copy link
Member

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.

Copy link
Collaborator Author

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));
Copy link
Member

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?

Copy link
Collaborator Author

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.

Copy link
Member

@zadjii-msft zadjii-msft left a 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 😍

@DHowett DHowett added the AutoMerge Marked for automatic merge by the bot when requirements are met label Oct 26, 2021
@ghost
Copy link

ghost commented Oct 26, 2021

Hello @DHowett!

Because this pull request has the AutoMerge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

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 (@msftbot) and give me an instruction to get started! Learn more here.

@ghost ghost merged commit 7b7dea0 into microsoft:main Oct 26, 2021
@ghost ghost removed the Needs-Second It's a PR that needs another sign-off label Oct 26, 2021
@j4james j4james deleted the consolidate-input-modes branch November 6, 2021 20:39
@ghost
Copy link

ghost commented Feb 3, 2022

🎉Windows Terminal Preview v1.13.10336.0 has been released which incorporates this pull request.:tada:

Handy links:

This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
AutoMerge Marked for automatic merge by the bot when requirements are met
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants