-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Scandinavian keyboard layout can't handle input tilde (~) #2151
Comments
VS Code issue: microsoft/vscode#68262 |
@Tyriar how |
vscode uses xterm, that's the issue that's been reported over there. |
Terminus has the same issue: Eugeny/tabby#768 |
I'm not sure if this ever worked if |
@Tyriar Using only |
I'm having the same issue in Fluent Terminal. |
Until this issue will be fixed I suggest using workaround from here |
I'm not sure if this exactly the same issue, but I find that typing any diacritics (like ö ầ etc), not just the tilde, on |
@GitSquared I think this might be related to your |
@Tyriar My Also, I'm unsure how |
@Tyriar Is this only an issue under Mac or with Mac keyboards (MBP)? I have no problems with PC keyboards with german keyboard layout - all third level shifts work as intented in all browsers (tested with demo in chrome + FF). Some ideas whats going wrong (in fact it looks like 2 separate issues on the lower level):
Key handling always has been a pain in the a** in browsers, maybe we can learn something from the monaco guys here? Things mentioned in this issue are hard to fix as long as we cannot repro it and dont know the exact circumstances this bug shows up (OS + browser version). Any volunteers to (partly) address this? To test if the browser reports the right thing you can use https://w3c.github.io/uievents/tools/key-event-viewer.html. |
@jerch you might be right OP and the 2 linked vscode issues are all on macos. |
FYI, a string of closed/duplicate issues on the VSCode repository lead me to this issue, and I'm on Windows. Using a French AZERTY layout, the tilde is on the "number" row, on the "2" key, which has as main char "é", shift char "2" and third char "~", which normally has a dead key behaviour. Thus, to type in a ~ character, the normal sequence would be AltGr+é, Space. However, when doing so the result is I'm not entirely certain it is the exact same bug, but I'm assuming it stems from the same root causes. |
@laarmen It seems we first have to identify the problematic layouts, AZERTY seems to be one of them. Our problem is that none of us can dig into that, we only use english/german keyboard layouts. So if you dont mind - could you also check if the other third shifts are wrong as well (I assume so)? And whether https://w3c.github.io/uievents/tools/key-event-viewer.html reports the right thing - if so its prolly a problem on our side. Edit: Here is a list of common latin keyboard layouts https://en.wikipedia.org/wiki/List_of_Latin-script_keyboard_layouts (and links to other layouts in the footer). And the ISO spec for keyboards https://en.wikipedia.org/wiki/ISO/IEC_9995. |
OK, so I tried to reproduce on a Docker xterm.js instance, and couldn't reproduce (Firefox and Chrome both). I'm on Windows 10, and my bug happens in the VSCode terminal (1.38.1). 🤷♂ |
@rebornix have you seen any reports around this for monaco? |
For me on macOS, Finnish keyboard, with Safari and Chrome a tilde + space results in ~ and tilde + n results in ñ as it should. But on Firefox a tilde + space results in ~~ and tilde + n results in ~ññ. Interestingly this behavior difference can be seen (but a bit differently for some reason) on the https://xtermjs.org/ home page example terminal. If you enter tilde + space there on Safari you get nothing at all. Same for tilde + n. But with Firefox while tilde + space gets you nothing a tilde + n gets you ñ. Not sure why it's working differently there. Debug logging shows the following when typing tilde + space on Firefox:
For tilde + n it shows:
Note that there are differences in browsers with regards to what is reported from e.g. compositionend vs. input vs. keydown vs. keypress events. I should add that nothing is being sent until you hit space or n. That is, the initial tilde that starts the character compose does not result in any callbacks firing, whch is correct. |
As @Tyriar set that issue as a duplicate of this one, I am posting here that nothing solves for me. I tried to re-install VSCode, change terminal to use ZSH shell, change the VSCode language and added configuration "terminal.integrated.env.linux" to use UTF-8. I personally don't think this is the same problem of that issue because I am using Ubuntu and when I type (in VSCode terminal) a special char alone and press space it works ex.: "^~`'", but when I type a special char like "^" + "a" only show "a" instead of "â". Same with "áâãéẽíĩóú". But in normal Ubuntu terminal everything works ok. Does anyone have any more ideas? |
@alexandrehpiva Can repro that under ubuntu with chrome and QWERTZ (german layout), where ^ is a dead key. I think dead key composition never worked correctly for chrome under linux, while it works with firefox. Can you confirm - is ^ a dead key in your keyboard layout? (dead key - not producing a symbol on first press, instead adding some modification to a following key, often used to add ^, ~, ¨ or other accents to a letter) |
@Tyriar bad news, found out that some Windows machines just don't produce the "Dead" keydown no matter what. I'm investigating and I think we should reopen this for the time being. |
😦 |
I am seeing the same problem (which also impacts JupyterLab, where we use xterm.js) and wanted to mention that there's an easy way even for developers on US keyboards to reproduce it, which may help track it down: I'm on a Mac, and if you install the "US International" layout: that will give you dead keys for accents in western languages (I use it as I have to type regularly in English, Spanish and French + coding and my keyboards are US-layout). With this layout active, to type say As of right now, testing this on the xtermjs.org terminal with this layout does not work (nor do other accents). I hope this helps the dev team perhaps track it down better - we'd greatly benefit from a fix to this on the JupyterLab team... LMK if I can provide further testing/feedback (no fixing offered - I don't know this codebase/JS well enough to help, sorry!!). Otherwise thanks for the fabulous tool! |
No, it isn't. My keyboard is pt-BR Brazilian Portuguese. Really, my problem explanation is like the |
@alexandrehpiva do you still get the problem on VSCode? I just tested it on my current setup (VSCode 1.59.1 on MacOS Big Sur, with US International layout) and it's now fine. Just checking to see if with current versions of VSCode it still happens, to help narrow down things. |
Yes, I just update to 1.60.0, and still same problem. I'm unable to use accented characters with Ubuntu bash inside VSCode. I tried to install and use Oh My ZSH too and still same. The mad thing is that work's perfectly in terminal outside VSCode. Anyone knows how to change configuration for this (if exists) in Ubuntu 20.04 LTS? |
I realized the same thing today. If I press the tilde key followed by the "a" key, it is displayed |
Ubuntu 20.04 using GNOME and having the same issues. |
Same problem here with vscode integrated terminal in Ubuntu 20.04 GNOME. |
For those using Ubuntu 20.04. 1.Install ibus:
and now everything is just working fine: |
Now I'm not using Ubuntu 20.04 anymore, I upgraded to Ubuntu 21.10 and VSCode 1.66. I noticed that |
To type
~
with Finnish/Swedish keyboard I have to press hotkeyalt+^
:After that it shows something similar to
~
but right after when I press any other character (except Enter) it will erase "pre-tilde" symbol. PressEnter
"converts" to normal ~ and nothing more (without real Enter).I checked how this works with vanilla JS and it seems something wrong at browser-level:
Is it fixable? Wdyt?
Related bugs:
#174
Details
Chrome (latest)
MacOS X (latest)
3.14.0
Steps to reproduce
The text was updated successfully, but these errors were encountered: