-
Notifications
You must be signed in to change notification settings - Fork 8.5k
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
Ctrl+Alt+Shift+2 doesn't send NUL in VT input mode #5205
Comments
|
Okay I see what the problem is - I think it is the think @lhecker called out in #4192. Even in straight-up conhost, Ctrl+alt+shift+2 does not generate IMO, @lhecker if you want to do the fix proposed in #4192, the I'll submit the other thing I found during the course of this investigation, but that will effectively hide the |
@zadjii-msft I believe we're misunderstanding each other. If I press Ctrl+Alt+Space or Ctrl+Alt+Shift+2,
But as far as I can see it should be That said, would you'd like me to modify #4192 to use a |
Oh jeez, you should be seeing |
I figured it out. I didn't realize I had to manually attach myself to OpenConsole.exe for debugging. 🙈 Anyways... I fixed the problem. (lol) I replaced this: terminal/src/terminal/input/terminalInput.cpp Line 488 in 713550d
with a call to Would you like me to add it to #4192 or open a separate PR afterwards? |
Literally my least favorite thing about using VS. JUST ATTACH TO CHILD PROCESSES. Or at least give me an option to auto-attach, sheesh.
You're sure right about that 😄 Glad you got that figured out!
Let's open another PR, since this has gotten bigger than a oneline fix |
MY HERO |
Time to e-mail the entire team this finding |
…e's a problem in Win32 quite yet. (#5208) ## Summary of the Pull Request When conpty is in VT input mode, we pass through all the input we receive. This includes all the other `Action*Dispatch` methods, but missed this one. ## References * Missed during #4856 * Discovered during the course of the #4192 review * #5205 Also investigated part of the issue, but found a different bug. ## PR Checklist * [x] Doesn't close anything, just related to above things. * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments This will fix the <kbd>ctrl+alt+space</kbd> in the Terminal thing mentioned in #4192, but doesn't actually resolve the root cause of that bug (which is tracked in #5205).
Milestoning this for 1.x and taking off Triage |
## Summary of the Pull Request Fixes #5205, by replacing another use of `MapVirtualKeyW` with `ToUnicodeEx`. The latter just seems to be much more consistent at translating key combinations in general. In this particular case though it fixes the issue, because there's no differentiation in `MapVirtualKeyW` for whether it failed to return a character (`'\0'`) or succeeded in turning `^@` into `'\0'`. `ToUnicodeEx` on the other hand returns the success state separately from the translated character. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #5205 * [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 * [x] 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: #5205 ## Detailed Description of the Pull Request / Additional comments This PR changes the behavior of the `Ctrl+Alt+Key` handling slightly:⚠️ `ToUnicodeEx` returns unshifted characters.⚠️ For instance `Ctrl+Alt+a` is now turned into `^[^a`. Due to how ASCII works this is essentially the same though because `'A' & 0b11111` and `'a' & 0b11111` are the same. ## Validation Steps Performed * Run `showkey -a` * Ensured `Ctrl+Alt+Space` as well as `Ctrl+Alt+Shift+2` are turned into `^[^@` * Ensured other, random `Ctrl+Alt+Key` combination behave identical to the current master
Dustin L. Howett (3) * Move CharToKeyEvents (and friends) into InteractivityBase (GH-9106) * Update Cascadia Code to 2102.03 (GH-9088) * verison: bump to 1.7 on main Josh Soref (1) * ci: update to Spell check to 0.0.17a (CC-9014) Leonard Hecker (3) * Fixed GH-5205: Ctrl+Alt+2 doesn't send ^[^@ (CC-5272) * Fix issues in tests.xml and OpenConsole.psm1 (CC-9011) * Fix GH-8458: Handle all Ctrl-key combinations (CC-8870) Mike Griese (1) * Add support for running a commandline in another WT window (GH-8898) Michael Niksa (1) * Teach the renderer to keep thread alive if engine requests it (GH-9091) Lachlan Picking (1) * Fix shader time input (CC-8994) PankajBhojwani (1) * Separate runtime TerminalSettings from profile-TerminalSettings (CC-8602) Chester Liu (2) * Add support for paste filtering and bracketed paste mode (CC-9034) * Add support for chaining OSC 10-12 (CC-8999) Related work items: MSFT-31692939
🎉This issue was addressed in #5272, which has now been successfully released as Handy links: |
@zadjii-msft:
@lhecker:
Okay I maybe saw what happened here.
\x1b\x0
, it converts it to [Shift_down, Ctrl_down, Alt_down, 2_down, 2_up, Alt_up, Ctrl_up, Shift_up].TerminalInput::HandleKey
, we end up skipping that branch, because thech
was0n50
, which is0x32
, which is'2'
.I'm not sure what's exactly the right behavior here. I'd think we probably should send a different key, but I'll need to investigate more. It's possible that the
ch != 0
change would work just fine, but I want to make sure that the upstream input from conpty is actually correct.I've got a braindead fix that would fix
showkey -a
, but that doesn't really resolve the issue here for Win32 applications unfortunately, so I'm gonna file a separate issue to track this investigation.Originally posted by @zadjii-msft in #4192 (comment)
The text was updated successfully, but these errors were encountered: