Keybinding discussion (non-US mostly)

[AntonAderum]

Hi!

(Note: This became quite long. but the question have quite a lot of history in it so I had a hard time making it shorter...)

We have started using vscode as our developing tool at work, and since im a long time vim user I've been looking for a good vim-extension. As far as I can tell this is the best and most ambitious project.

However the keybindings for non-us keyboard are not optimal. I know this is mostly because of vscode using Electron (Atom has the same problem), and I know you have had some discussion about it already: #49 here discusses it and @guillermooo even created an issue over at vscodes repository.

There's also the issue over at vscode repo that discusses this at length: microsoft/vscode#713

The end result of that issue created the Keybinding widget (which is great), and also fixed key-bindings in general for non-us keybindings.

When I tried using the Keybinding widget I noticed that the "<"-key was still not working on my (Swedish) keyboard. So I submitted an issue (microsoft/vscode#1794) and it got fixed to the master branch just the day after. I have built vscode from source and testet that it works. Great!

pressing the < key in using the Keybinding widget will result in this:

{
    "key": "oem_102",
    "command": "commandId",
    "when": "editorTextFocus"
}

Now I have noticed that you guys have the keyboard.ts file that tries to handle keybindings for different layouts, this also works fine - except for when there are keys that you havent declared in package.json since these wont be handled (and so never gets to be "translated").

So if i tried to create a swedish KeyMapper in keyboard.ts i would do this:

this.mappings = {
            'oem_102': '<',
            'shift_oem_102': '>'
        };

But that wouldnt execute because oem_102 would never be handled and and sent to that translate function i just created.

This isnt just a problem with oem_102 but really with every key that isnt handled in package.json

Sooooo, I guess my question is: How do you want to handle translating keys that arent in package.json? Should we simply add lines in package.json like this:

{ "key": "oem_102", "command": "extension.vim_oem_102", "when": "editorTextFocus" },
{ "key": "Shift+oem_102", "command": "extension.vim_shift_oem_102", "when": "editorTextFocus" }

And then do the mapping I did above (+ actually writing the command as well of course)?
This seems to work fine (only way to test at the moment is to run from source), and it will allow me to indent using the actual < button on my keyboard.

[AntonAderum]

Let me know if you have any questions, I realize this became quite long and maybe over complicated.
Maybe I spent to much time thinking about it but I felt like it could use a discussion. I will create a PR where you can see the changes together.

[jpoon]

Hey @AntonAderum.

I think what you suggested is the best course of action. For whatever keys the extension wishes to handle, they need to be registered with VSCode in the package.json and a respective handler defined in extension.ts.

[guillermooo]

Just a quick note that we may not need the internal key translation done by VSCodeVim any more. I've fallen behind with the current status regarding key handling in VS Code, though, so this is just a heads-up.

[jpoon]

@guillermooo 😮

What's the new way of handling these things then?

[AntonAderum]

@jpoon Great!

@guillermooo
As far as I can tell (with what i have been reading last few days) you will still need to take internal key and translate it to the proper key via handlers. I'd be delighted if it wasnt the case though.

[kedare]

I saw some issues of this kind, for example on my keyboard (Spanish) pushing ":" is like pushing ">" (or "<", I don't remember) when using the VIM plugin (And I never had any other problem of this kind somewhere else in VSCode), this is quite a problem :)

[jpoon]

Closing this issue as VSCode has made some great headway in handling international keyboards: #432. We've actually removed our own keyboard mapper in favor of letting VSCode handle the dirty work.

If you don't think that is the case, please re-open this issue.