Open gpotter2 opened 3 years ago
Thanks for the "un-deadifying-of-keys" idea. I almost got crazy today after updating from 1.6.10571.0
to 1.7.X
/ 1.8.X
/ 1.9.X
and noticing that despite having altGrAliasing
turned on, I couldn't input any of {
[
]
by Ctrl-Alt
ing them. Reading through the issues, I noticed this problem pops up every now and then...
Following solved the issue (not a very nice solution though š Probably there are also other dead keys I will need to wake up ... )
...
{
"command": {
"action": "sendInput",
"input": "{"
},
"keys": "{"
},
{
"command": {
"action": "sendInput",
"input": "["
},
"keys": "["
},
{
"command": {
"action": "sendInput",
"input": "]"
},
"keys": "]"
}
...
@gpotter2 What language are you using the AZERTY layout with? For French AZERTY AltGr+9 (^) is not a dead key.
@gpotter2 What language are you using the AZERTY layout with? For French AZERTY AltGr+9 (^) is not a dead key.
There is another one accessible with a single keypress (in red on the picture, near the enter key)
@gpotter2 Just to explain my previous comment a bit better: This issue exists due to https://github.com/microsoft/terminal/pull/2235
For instance if you use a German keyboard Ctrl+Alt+7 and AltGr+7 will both produce the rather important character {
. Since WT's settings don't differentiate between left and right Alt, it doesn't differentiate between Ctrl+Alt and AltGr. https://github.com/microsoft/terminal/pull/2235 prevents AltGr+combinations from ever reaching your keybinding settings, allowing you to have a key binding for Ctrl+Alt+7 (aka "focus tab 7") while simultaneously being able to press AltGr+7 to write a {
.
Fixing this issue is very complicated and quite likely requires us to change the meaning of the "Ctrl" and "Alt" keywords when writing key bindings, in order to resolve the conflict with AltGr. I don't know what the best course of action is. Preferably it should be something that doesn't break existing work flows of our users.
I see. That's very clear thank you. Understandably being able to bind Ctrl+Alt+? to shortcuts is much more important than overriding altgr shortcuts.
The obvious solution would be for WSL to be able to differentiate altgr and alt but that's of course more easily said than done.
Windows Terminal version (or Windows build number)
1.9.1445.0
Steps to reproduce
The AZERTY keyboard for context:![](https://camo.githubusercontent.com/b684d428ce04f860921ba21c5b42e65a861f497f16f64c48b2779b4a2ccce5e9/68747470733a2f2f75706c6f61642e77696b696d656469612e6f72672f77696b6970656469612f636f6d6d6f6e732f7468756d622f622f62392f4b425f4672616e63652e7376672f35303070782d4b425f4672616e63652e7376672e706e67)
keybindings
to "un-deadify" some keys:Actual Behavior
Both ^ and ~ keys are dead keys.
^
shows up instantly and doesn't act as a dead key.~
it does work great when doing ctrl+alt+\~ (whataltgr
is an alias of), but not when using altGr+\~:~
to show up)altGrAliasing
was turned on.Comments
This issue follows my previous https://github.com/microsoft/terminal/issues/5784 issue. TBF, this is the edge case of an edge case, and I would understand if this never got fixed... I'm just secretly hoping for another
@lhecker
miracle š but can probably live without it