Locali(s)(z)ed keyboard support for 3rd level characters

[exsilium]

This patch includes support-beginnings for locali(s)(z)ation needed by countries where keyboard includes third-level characters.
Characters like @|{[]}\ are currently often not usable because they are mapped as 3rd level characters on different international keyboard layouts.

• kbLayout option introduced, which can be given during Terminal.call and changed even after, defaults to 'us';
• Placeholders for the following layouts:
  -> French (fr);
  -> German (de);
  -> UK (uk);
  -> South Slavic Latin countries - Croatia (hr),Slovenia (si), Bosnia and Herzegovina (ba), Serbia (rs);
  -> Belgium (be);
  -> Polish (pl);
  -> Turkish (tr);
• Placeholder keyboard layouts currently output "Not Implemented" to browser console;
• Estonian (ee) keyboard layout implementation for Windows (AltGr) and Mac (Alt);
• Should not break anything that was working before...

This patch will hopefully pave way for others to include their specific country layouts and solve issues like reported here: chjj/tty.js#64

[rmtew]

This looks like a typo, and that it should be "else if".

[tonila]

Tested with "else if" and it did not work.

[exsilium]

It will not work with "else if" - with the current implementation it needs to be always executed if the condition is true. Otherwise the execution stops in one of the previous else ifs. For example @ line 2599:

} else if ((!this.isMac && ev.altKey) || (this.isMac && ev.metaKey)) {

What platform, browser and which kbLayout are you testing out with, other than ee you will only receive 'Not implemented' in your browser log.

[tonila]

Nice. This estonian implementation works also for finnish keyboard layout. Maybe swedish too.

[exsilium]

Oh didn't see this comment, glad it works for fi. You can add the fi and se country codes as well - glad that someone can test this patch!

[GottZ]

to be honest there is a de-latin1-nodeadkeys layout in arch linux. using it will bind third level characters to every key

[exsilium]

@GottZ - Curious, what did you mean by that comment, a missing placeholder? This is true, the implementation I wrote is "ee" specific as it was the only layout I could reliably test, I added the placeholders for only the specific layouts I had knowledge of at the time.

As it hasn't been merged by the original author I'm still using it as a hack - maybe there's a more elegant way in getting the 3rd level characters to work..

[GottZ]

well i mean, as soon as i type and kind of altgr + key combination the char will not be visible.
what makes me wonder though is.. it works fine on linux desktops. maybe because for microsoft it does not matter if you press ctrl + alt or altgr and for x11 it differs.

if i can find some time i'd be happy to create a commit to fix this issue global. i've got an idea that might work without breaking anything.

[exsilium]

This patch already fixes that and should work for you as well as soon as you add your country specific mappings.

3rd level mappings differ from country to country so the same key combination or code is used to represent different characters:

German: http://en.wikipedia.org/wiki/AltGr_key#German
Estonian: http://en.wikipedia.org/wiki/AltGr_key#Nordic_and_Estonian

There are of course similarities so you can even try this patch without modification, use the 'ee' layout and in your keyboard the Altgr+7, Altgr+8, Altgr+9, Altgr+0 should map correctly to your layout and the character should be visible.

In terms of a global fix, one would probably need to use keypress event instead of keydown to get directly the actual character that the OS/Keyboard is mapping to, making the kbLayout parameter obsolete but requires a bigger rewrite.

The mapping you are using from OS does not matter to term.js or Javascript. Because the keyDown event is oblivious to the keyboard mapping in use.

[GottZ]

hm. by digging deeper into the solution i have in mind i noticed it would only work in webkit..

there is a textinput event that is getting fired if keydown / keyup dont get prevented.
using that would allow to actually grab the character that would have been written by pressing something like ctrl + alt + q to get @ etc.

however as i said.. that would only work in webkit. still worth implementing i think because it would make key maps obsolete.

[exsilium]

Not sure about the "worth" part. textinput event is scoped and only fired in certain elements (might be wrong here..) and you'll have issues getting the other keys like up-down arrows and such to work plus you'd need to change the UI side of things. However, If you do get it to work, yes, you'd be free of the mappings! 👍

Not trying to discourage you, btw! If you get it to work I'm always up to trying the patch out! Apart from defining the maps, which is a one time effort, there's no bigger re-write of anything else with my approach - it simply works and that was the original appeal to me :) Let's face it, it seems to be serving only "minority" interests here. I'm not sure if it's ever going to be pulled in or what the maintainer thinks of this patch as he hasn't commented on it 🎱

[exsilium]

@chjj any comments on this one? It shouldn't break anything for people using default us keyboard and merging this would enable me to consume upstream 👀

Other more exotic kbLayouts can be added as needed...

[yoshiokatsuneo]

I tried to handle the issue by hidden textarea (Especially Japanese for me)
#97

[rgbkrk]

A worthy fork that seems to be moving on and welcoming your patches exists in https://github.com/sourcelair/xterm.js, maintained by @parisk.

[exsilium]

@rgbkrk Thanks, I'll check it out!

[parisk]

@exsilium we would be happy to work with you on this at xterm.js, where we have an open issue that seems to match this PR (xtermjs/xterm.js#33).

Thanks for the mention @rgbkrk.

[exsilium]

We've all moved over to https://github.com/xtermjs/xterm.js and this project is no longer maintained. Closing this PR and cleaning up. 📯 🚀