Vim: Command executed hides the mode display on status bar

[stevenguh]

The mode display on status bar is overridden by command executed by Vim when a command and the mode display is only returned switch a user switch mode.

For example: if the follow command is executed, it will show the "vspacecode.space" on the status bar, and the current mode will be hidden until the next mode switch.

  "vim.normalModeKeyBindingsNonRecursive": [
    {
      "before": ["<space>"],
      "commands": [ "vspacecode.space"]
    }
]

Describe the solution you'd like
The status bar message will timeout and return back to current mode display automatically.

Describe alternatives you've considered
Here are some alternatives that I thought of:

1. A setting to disable the display of the commanded by vim.
2. Not display command executed
3. Have a command a third-library can call to reset to mode display
4. A flag in the remapping setting of Vim like

  "vim.normalModeKeyBindingsNonRecursive": [
    {
      "before": ["<space>"],
      "commands": [{
                    "command": "vspacecode.space",
                    "args": "m",
                    "displayOnStatusBar": false
                }]
    }
]

(This seems very verbose if each command has displayOnStatusBar)

Additional context
This issue was filed in the extension I maintain which relies on VSCode Vim https://github.com/VSpaceCode/VSpaceCode/issues/137.

I believe this is where vim set the message
https://github.com/VSCodeVim/Vim/blob/119cf137d6bdc968a4f0e150de28dfc1caaba22a/src/configuration/remapper.ts#L527, and I can help to get a PR if we agree on how we should handle it.

[J-Fields]

My preference for a first step would be Vim's behavior - no timeout, but as soon as the view scrolls, the command line is cleared. I'm pretty sure it used to work like that in VSCodeVim (at least for error messages), but it's apparently regressed (or maybe I'm misremembering).

The proper way to support this is via :map <silent>. That's probably not too difficult, but it'll require some thought.

Let me know if these will satisfy your use case.

[stevenguh]

My preference for a first step would be Vim's behavior - no timeout, but as soon as the view scrolls, the command line is cleared.

I agree that we should stick close to Vim's behavior. I just played with current Vim version a little bit. This is implemented, but it's not that robust. I had to smash the <C-D> and <C-U> to reset the status bar. Maybe we should look into why it is not robust.

The proper way to support this is via :map

From a glance, that seems like the option I mentioned but in more Vim way and flexible. I am sure not how it would interact with the current system in VSCode. I might not be much of a help here.

@mmcnl, since you opened the original issue, does any of these satisfy your use case as well?

[berknam]

I think the <silent> option is the better one. I thought about implementing that when I did the remapper overhaul, but decided against it because it was one more thing to add to the already big overhaul and didn't know if it would bring much benefits. I did make it so .vimrc mappings builder is ready to capture any mappings with <silent> from the .vimrc file, it was just ignoring that flag.

I do see how this would be very helpful for the vspacecode extension! We could implement it this way:

"vim.normalModeKeyBindingsNonRecursive": [
    {
        "before": ["<space>"],
        "commands": [ "vspacecode.space"],
        "silent": true,
    }
]

This would help on remaps like this as well: (similar to nmap <leader>s /searchstring<CR>)

"vim.normalModeKeyBindingsNonRecursive": [
    {
        "before": ["<leader>", "s"],
        "after": ["/", "s", "e", "a", "r", "s", "t", "r", "i", "n", "g", "<enter>"],
        "silent": true,
    }
]

PS. We really need to implement some sort of simple remaps like in VIM, something like this would be much better than the above:

"vim.remaps": [
    "nnoremap <space> vspacecode.space", // <- it would be easy to add <silent> here
    "nno <leader>s /searchstring<enter>" // <- it would be easy to add <silent> here
]

On the vscode commands we could go the VsVim (from VisualStudio) way and create a :vsc command specific to run vscode commands like this:

"vim.remaps": [
    "nno <silent> <space> :vsc vspacecode.space",
    "nno <silent> <leader>s /searchstring<enter>"
]

@J-Fields Do you know if there was any reason why this approach was never an option? (both the "vim.remaps" and the ":vsc")
I think we could add this "vim.remaps" while keeping the other ones for compatibility.

[berknam]

On the vscode commands we could go the VsVim (from VisualStudio) way and create a :vsc command specific to run vscode commands like this:

I knew I had done some work on this before! Here I have a branch were I started to implement something like this, basically instead of :vsc I'm using a single special key with this format <CMD-commandName> this would work like this:

"vim.normalModeKeyBindingsNonRecursive": [
    {
        "before": ["<space>"],
        "after": [ "<CMD-vspacecode.space>"],
        "silent": true,
    }
]

The problem with this approach and the one above is that it won't be easy to allow for command args, we could do something like :vsc vspacecode.space("m") or :vsc cursorMove({ "to": "wrappedLineEnd", "select": false, "by": "character", "value": 1 }) in this case we would need to parse the args object from a json type.

@stevenguh I'm sorry for hijacking your issue! 😁

[stevenguh]

Thanks for all the helpful examples. That silent option in the json mapping makes sense, and will definitely solve the problems with vspacecode, and matches the <silent> option in Vim.

As far as for the side discussion on vim-like remapping in the settings.json, I am supportive and seems to be more aligned to .vimrc. Like you called out, the :vsc command is going to look weird when we have a large amount of parameters to pass through or executing multiple commands.

---

I guess my takeaway is

1. Resetting mode display by scrolling is not that robust for some reason
2. silent options would definitely solve the use case for vspacecode
3. Having :vsc can be useful for .vimrc so it will be feature parity with the existing mapper bindings in settings.json
4. Having vim-style remap and existing mapping will make allow the config to be more consistent to vim-style.

I am not sure about adding another config type in the settings.json(aka 4.) especially in terms of maintainability. But it is certainly nice to have for me and can make config more aligned to vimrc for sure.

[J-Fields]

@J-Fields Do you know if there was any reason why this approach was never an option? (both the "vim.remaps" and the ":vsc")

Nope. Frankly I hate the way remaps currently work in settings.json - this seems like a better way to go. Perhaps at some point we compile all the breaking changes we want to make and stick them in a 2.0 release with a script or something to make the transition as painless as possible.

[J-Fields]

Seems the regression regarding viewport scrolling was caused by this. I think we might be able to have our cake and eat it too, but for now I'll revert. Never mind, I figured out how to implement this properly.

[stevenguh]

Thank you for fixing the scroll reset. It works flawlessly now :)

[berknam]

@J-Fields Do you know if there was any reason why this approach was never an option? (both the "vim.remaps" and the ":vsc")

Nope. Frankly I hate the way remaps currently work in settings.json - this seems like a better way to go. Perhaps at some point we compile all the breaking changes we want to make and stick them in a 2.0 release with a script or something to make the transition as painless as possible.

It is possible to have both ways (the current one and "vim.remaps"). This way the current one could be used easier for calling commands with args. In case of the same key being remapped we would give priority to the current method (since it takes more effort to write it down! 😄) This basically means that we would first read remaps from "vim.remaps" and after that we would read remaps the current way (any repeated remap would be overridden by the last step).

This would maintain compatibility and give a simpler alternative for all the remaps that don't require commands with arguments (which is almost all of them!)