You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Windows Terminal 1.1 breaks WinCompose input #7089
Windows build number: 10.0.19041.0
Windows Terminal version (if applicable): 1.1.2021.0
Any other software?
Ubuntu 20.04 LTS (WSL2)
WinCompose v0.9.4 (https://github.com/samhocevar/wincompose/releases/tag/v0.9.4)
Steps to reproduce
Start WinCompose and Windows Terminal (cmd, powershell, or WSL does not matter)
Input any character using the WinCompose compose key
e.g. rightAlt + oa
Expected behavior
The correct character ('å' in the above example) is sent to the terminal.
Actual behavior
Seemingly no character is sent, at least nothing is displayed.
Probably related to #6309 as setting "experimental.input.forceVT": true gives the expected behavior.
Reacted by Martin Keogh, Damien LeBerrigaud, Frank Blendinger and tfkls
As far as I can see, this issue was fixed in #7900. I'll close this issue for now as WinCompose works just fine on my end with the latest WT version.
The good thing is that I now finally understood, why we've been receiving weird key events, containing invalid scan codes, for third party applications employing SendInput: WT doesn't use TranslateMessage(Ex) properly. (I mean there's a very specific reason it doesn't... Namely the necessity to receive key events even for character keys.)
Reacted by Sam Hocevar, Frank Blendinger and mordquist
I don't know if maybe this problem got recently reintroduced, but WinCompose currently does not work with any window terminal on my machine (cmd, powershell or windows terminal). When typing rightAlt'a, it just outputs 'a and the compose key is ignored.
I tried the "experimental.input.forceVT" setting, but it doesn't seem to do anything.
I just found the problem. It didn't work because I was running the terminals in administrator mode, but WinCompose did not have admin privileges. When WinCompose is run as admin, everything works fine.
Activity
DHowett commentedon Jul 27, 2020
Huh. This doesn't exactly work in the traditional console either, and it was somewhat of a fluke that it worked in WT. It should, though.
This is what I get if I peek at the key events coming out of WC into the traditional console:
and here's what I'm getting over the tap:
␛[255;0;0;1;16;1_␛[255;0;0;0;16;1_that 255 definitely ain't right
samhocevar commentedon Nov 26, 2020
So, how should a third-party application send Unicode characters to Windows Terminal if
SendInput()no longer works by default?lhecker commentedon Nov 26, 2020
As far as I can see, this issue was fixed in #7900. I'll close this issue for now as WinCompose works just fine on my end with the latest WT version.
The good thing is that I now finally understood, why we've been receiving weird key events, containing invalid scan codes, for third party applications employing
SendInput: WT doesn't useTranslateMessage(Ex)properly. (I mean there's a very specific reason it doesn't... Namely the necessity to receive key events even for character keys.)mordquist commentedon Nov 30, 2020
I can confirm that it works for me as well on Terminal 1.4 even with
"experimental.input.forceVT"unset.smooth038 commentedon Apr 15, 2023
I don't know if maybe this problem got recently reintroduced, but WinCompose currently does not work with any window terminal on my machine (cmd, powershell or windows terminal). When typing
rightAlt'a, it just outputs'aand the compose key is ignored.I tried the
"experimental.input.forceVT"setting, but it doesn't seem to do anything.Can anyone else reproduce this?
smooth038 commentedon Apr 15, 2023
I just found the problem. It didn't work because I was running the terminals in administrator mode, but WinCompose did not have admin privileges. When WinCompose is run as admin, everything works fine.