Pressing "v" on DVORAK layout commits autocorrect

[Tsmith18256]

• VSCode Version: 1.7.1
• OS Version: Windows 10

This is a fun one... I use a Programmer-DVORAK layout, and the autocomplete commits whenever I type the letter v. The issue goes away if I switch back to QWERTY. It is pretty clear what is happening here; the v on DVORAK (or Programmer-DVORAK) is where the period is on QWERTY, which is intentionally meant to complete the autocorrect.

This is odd behaviour since the editor handles all the keys properly when typing and using hotkeys, but for some reason fails to distinguish the character being typed here. It also might be good to note that it still inserts the letter v after the committed word, not a period. I also noticed that the standard behaviour of committing the suggestion does not happen when hitting the DVORAK's period, it just inserts a period.

Also, if it makes a difference, the version of Programmer-DVORAK I am using is set to use QWERTY hotkeys, similar to the DVORAK-QWERTY layout that comes native on OS X.

Steps to Reproduce:

1. Enable Programmer-DVORAK on your computer (normal DVORAK would probably cause the issue as well. I have a Programmer-DVORAK keyboard layout file on Windows that I created for anybody that would like it)
2. Create a new TypeScript file with a class in it.
3. Attempt to add a private property.
4. Notice that it commits to the suggestion of "print" when you get to the v, resulting in the final word you get being "printv."

In the meantime, is there a way to disable this behaviour when pressing period? I can't find a setting for it.

[ramya-rao-a]

To disable autocomplete on pressing period, you can set "editor.suggestOnTriggerCharacters": false
With this, you hit Ctrl + Space to trigger the suggestions

[HookyQR]

I thought I'd have a shot at fixing this problem, and have had not problems with any 'correct' bindings on the current master by simply commenting out the if (Platform.isMacintosh && _b24_interestingVirtualKeyCodes[e.keyCode] && typeof (<any>e).keyIdentifier === 'string') block.

I'll hack the 1.7.1 and current 1.8 build internals and see if the same 'fix' works. If so, I guess the mac specific thing is (no longer) an issue. More to follow ...

[HookyQR]

Yep, that totally got rid of any issues. Code completion begins by pressing ., Cmd+P works. All with the actual key (ie, not 'where the key would be on a QWERTY keyboard).

[Tsmith18256]

@ramya-rao-a I just set that to false, but it is still committing on v in DVORAK and period in QWERTY.

@HookyQR If you post a fix, I'll be happy to test it out on my computer. I have never run the app from the source code for this project yet, but I can get it set up.

[HookyQR]

@Tsmith18256 on windows or mac? Are you using some other program to re-map your keyboard? I'm using the default Dvorak. Also, are you on Sierra? You'll have to remove any 're-mappings' you've setup already. (In VSCode)

[HookyQR]

@Tsmith18256 Sorry, I misinterpreted what you were saying there.

It's an easy hack:
In /Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js
/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/electron-browser/workbench.main.js
Change if(s.isMacintosh&&g[e.keyCode]&&"string"==typeof e.keyIdentifier) to if(0&&s.isMacintosh&&g[e.keyCode]&&"string"==typeof e.keyIdentifier).

[HookyQR]

See PR #15687

[jrieken]

There is keyboard config-rule that goes like this:

{ "key": ".",                     "command": "^acceptSelectedSuggestion",
                                     "when": "editorTextFocus && suggestWidgetVisible && suggestionSupportsAcceptOnKey && editorLangId == 'typescript'" },

So, when pressing . it will accept the selection suggestion if possible. Disabling that should help you to at least work around the issue. To disable have this

{ "key": ".",                     "command": "-acceptSelectedSuggestion" },

[HookyQR]

@jrieken see #1492. It makes other dumb things happen. See PR #15687. Why are you all so intent on requiring users to have to work around your bad work around. In this case, drop the two negatives and provide a keybindings for the users the original work around was for.

[alexdima]

This has been fixed in the meantime, I just got around to validating: