xterm.js: Scandinavian keyboard layout can't handle input tilde (~)

🥳 The workaround mentioned earlier https://github.com/xtermjs/xterm.js/issues/2151#issuecomment-515116994 by @insertt worked for me (French keyboard). No more é~ in VS Code terminal with my French layout keyboard!

• Create / install the layout without dead keys per the instructions above (here is the one I built for me: French Keyboard layout for VSCode.zip)
• Reboot (otherwise, Win 10 did not took fully into account)
• In Win 10 / Language settings, add the new keyboard layout

(My PC is configured for US, but I use a French Keyboard)

I just discovered a strange thing: If I press the accent key 3 times and then press the letter, it works and I get: “~ã”

Any news about this issue? Is there a proposed pull request or something similar?

For those using Ubuntu 20.04. After a long searching I found out that vscode depends on ibus for the accents work on integrated terminal. the workaround :

1.Install ibus: sudo apt install ibus ibus-gtk3 2. Create the config file:

cat <<EOF >ibus.dconf
[general]
preload-engines=['xkb:br::por']

[general/hotkey]
triggers=@as []

[panel]
show-icon-on-systray=false
EOF

1. import it to dconf: dconf load /desktop/ibus/<ibus.dconf
2. init ibus with proper config: im-config -n ibus
3. activate ibus on GNOME: gsettings set org.gnome.desktop.input-sources sources "[('ibus', 'xkb:br::por')]"

and now everything is just working fine:

I just discovered a strange thing: If I press the accent key 3 times and then press the letter, it works and I get: “~ã”

I realized the same thing today. If I press the tilde key followed by the “a” key, it is displayed a in the terminal and not ã. But if I press the tilde three times and then the “a” key, ~ã is produced. I imagine the issue should not be closed yet. I’m on Ubuntu 20.04.3 and on Terminator and Gnome Terminal the accent works perfectly.

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 cd ~ I will type cd , then tilde, then space. The space keystroke makes the tilde dead-key become the normal tilde (instead of say ~ + n, which will become ñ with that layout.).

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!

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?

@ricpelo Thx alot. The problem comes from this:

While FF already gives the dead key accumulated character on final keydown in key, chrome just returns the raw key. I am not sure who is to blame here, imho the keyboard stuff in keydown is not well specced at all. It also shows that input gets the chars right in both cases. Thats quite a strong argument to move to input (we already figured that above).

But input has difficulties to correctly catch meta keys like Strg, Alt, AltGr (left/right option on OSX), esp. Shift in combination, but we need those in a terminal to promote any Strg+X and such. I guess we need a more complex event handler, that basically relies on input but does another decoration/translation of the char from meta key states states of “enclosing” keydown / keyup events. Sounds nasty, but should be doable. Still the testing is hard to do (no good way to automate this without physical interaction).

@jerch sure. Here I go:

Chrome:

Firefox:

Ok, I feel stupid, I didn’t noticed the NumLock on my first comment. I have a small keyboard without numpad and function keys, so I didn’t noticed.

However, even with num lock, it should work, so the underlying issue (use of the input event) is still present, I guess.

Nevertheless, I’m happy to have found the cause of my issue. Hope it helps!

Until this issue will be fixed I suggest using workaround from here

Terminus has the same issue: https://github.com/Eugeny/terminus/issues/768 This isn’t limited to Scandinavian keyboards. At least French and Spanish are affected too (any layout with the AltGr key and 2 steps accents feature I presume).

vscode uses xterm, that’s the issue that’s been reported over there.