Conflict with VSCodeVim's new status bar

[jamesgecko]

Very similar issue to #6.

VSCodeVim just added a new statusline. You press : to activate it anything you type goes into a text field in the status bar. When pressing enter, the expected behavior is to execute the typed command and return focus to the document. Instead, a newline is added to the document and the text field in the status bar retains focus.

When disabling endwise, VSCodeVim behaves as expected.

[jamesgecko]

Looking at the fix from last time, I think I see an easy permanent fix. Vim has a lot of modes (and more may be added to VSCodeVim in the future), but the only one that endwise should execute in is "Insert".

[suan]

For reference, for those who also use the Vim extension, adding this to my keybindigs.json did the trick (it effectively cancels the builtin endwise keybinding and adds a new one with the updated condition):

    {
        "key": "enter",
        "command": "endwise.enter",
        "when": "editorTextFocus && editorLangId == 'ruby' && vim.mode == 'Insert'"
    },
    {
        "key": "enter",
        "command": "-endwise.enter",
        "when": "editorTextFocus && editorLangId == 'ruby' && vim.mode != 'SearchInProgressMode'"
    }

[xconverge]

This is a good solution ONLY for users of vim, if you want to commit another temporary fix and hope that we don't add more modes you can add this to package.json

&& vim.mode != 'CommandlineInProgress'

I am not sure what the best "permanent" solution and commit to the codebase would be

[jamesgecko]

What about changing the condition in package.json to something like this?

"when": "editorTextFocus && editorLangId == 'ruby' && (vim.mode ? vim.mode === 'Insert' : true)"

[xconverge]

Can you do that in package.json? You can't even || so I would be surprised if the ternary operator exists...

microsoft/vscode#22778

[kaiwood]

Thanks to all for the info about the issue.

Directly checking for 'Insert' mode is not possible, because that would always return false if the plugin is not installed. CommandlineInProgress is the way to go (thanks @xconverge).

I'm still looking for a somewhat cleaner approach than overloading the whole enter key, because there might be other plugins that collide with this. Couldn't find an alternative yet, might need to do more research on the topic.

[georgevreilly]

In Normal mode in Vim and VSCodeVim, I expect Enter to move me to the first non-blank character on the next line: http://vimdoc.sourceforge.net/htmldoc/motion.html#%3CCR%3E. It's baked into my muscle memory, so it was a rude surprise to find the behavior of Enter changed when I started editing Ruby code. Endwise was one of number of packages that were suggested installs at work. For now, I'm disabling Endwise since I wasn't knowingly using it.

I'm perfectly happy hitting Cmd+Enter to get Endwise's smart end behavior. If this were classic Vim, the usual way to handle this would be to detect the value of a global variable that can set in ~/.vimrc before importing the plugin, allowing a chance to override the default keybinding. I haven't dived deep enough into VSCode yet to know what the idiomatic way of accomplishing this is. I did try binding "<CR>" in "vim.normalModeKeyBindingsNonRecursive" in settings.json to restore the default behavior, but I couldn't get it work.

[kaiwood]

@georgevreilly Hah, didn't even occur to me that Normal mode needs to be excluded as well, as I never use enter in there (Having jw hardwired for the past 20 years).

I just released 1.4.2 that fixes this, it should now work as expected and no longer trigger in your case.

As for the question about the keybinding: You can't disable it if you just use the settings of the Vim plugin (keep in mind that it's a plugin and not the standard VSCode way for settings shortcuts).

What generally works in cases like this is opening your global keybindings.json and unbinding commands from there with this entry (note the - sign at the beginning of the command name):

  {
    "key": "enter",
    "command": "-endwise.enter"
  },

[georgevreilly]

Thanks, @kaiwood! That fixed it.