Vim: Default `Go to File...` (CTRL+P) is not working properly

But doing this will disable the ability to move up in the selection like autocomplete

I use both. What is the solution you think ?

    "vim.normalModeKeyBindingsNonRecursive": [
        {
            "before": [
                "<C-p>"
            ],
            "commands": [
                "workbench.action.quickOpen",
            ]
        },
    ],

According to the changelog there’s now handling for CTRL+P so it can be remapped. I fixed the issue by disabling its handling in settings.json under vim.handleKeys setting.

E.g.

"vim.handleKeys": {
	"<C-p>": false
},

It should be a top priority to fix that. Ctrl + P is the most used shortcut in vscode. If it has conflicts with a plugin, I would consider this plugin to be useless. Workaround works, but revert the behaviour please. It’s a stupid idea to overwrite it in the first place.

There are (currently) 5 duplicates of this issue: #8581 #8587 #8588 #8590 #8594

According to the changelog there’s now handling for CTRL+P so it can be remapped. I fixed the issue by disabling its handling in settings.json under vim.handleKeys setting.

E.g.

"vim.handleKeys": {
	"<C-p>": false
},

But doing this will disable the ability to move up in the selection like autocomplete

The solution would be just to revert this commit. Is there any reasoning on why this when clause was changed? Ctrl-P is very useful to navigate completion suggestions and other lists, but outside of this situation, the previous behavior of allowing vscode handle this seems to be what most people expect here. (But now that I’m thinking about it, this commit is from april. Why did this started happening to a lot of people today?)

as the commenter before mentioned, please revert this. Any plugin breaking ctrl+p is really a no-go!

To remove any problems in the future with the vscode vim-plugin i’d suggest this config to fix the problem for anyone looking here for a fix (just put it into user settings.json):

"vim.handleKeys": {
    "<C-p>": false
}

Here’s the commit that made the change: https://github.com/VSCodeVim/Vim/commit/6aa8611eb704c0aafc350d0d09e0f9e47766a6f2 Changing the keybinding’s when clause to the previous one (using suggestWidgetVisible instead of editorTextFocus) it seems to be working as it used to.

According to the changelog there’s now handling for CTRL+P so it can be remapped. I fixed the issue by disabling its handling in settings.json under vim.handleKeys setting.

E.g.

"vim.handleKeys": {
	"<C-p>": false
},

Doing so will disable the ability to select the previous one in the prompt box.

cc @grosssoftware who authored #7261 . I’m not too up on the use of ctrl-p in vim, what is your use case for it?

IMO the fact that this key shadows vscode’s default ctrl-p behavior for quickopen file, which is pretty integral to the vscode user experience, necessitates some care if we are making this behavior the default. The previous behavior of allowing it to navigate suggestion list seemed like a good compromise given that it’s a common use of the key. Users who use ctrl-p in other situations can always update the ‘when’ expression of the binding themselves.

Another alternative if we want to keep the override behavior is to pop up a notification the first time that vim is intercepting this keybinding, and allow the behavior to be selected. This is what IdeaVIM (the vim plugin for IntelliJ) does.

@kossnocorp you’re quite right and I apologize for my tactlessness.

I only meant to convey, however unskillfully, that this bug is not only an annoyance, and not only breaks the plugin, but essentially breaks VS Code itself when it’s installed. Therefore I think no other feature, bug or work on this plugin is remotely close in importance until this is fixed. (If I were the maintainer I would pull this version until a non-broken version could be published.)

I base this on trying to introduce other people to this plugin (which I love), but which they quite rightly would not take seriously when it breaks VS Code so badly. If the project takes itself seriously, it would take this issue seriously.

Of course other life events take importance over work done for free on open source projects, I only mean that this is the most important work to be done on this project (by several orders of magnitude).

You can either disable the vim handler just like https://github.com/VSCodeVim/Vim/issues/8574#issuecomment-1712962173 said - or override the key bindings.

    {
      "before": [
        "<C-p>"
      ],
      "commands": [
        "workbench.action.quickOpen",
      ]
    },

This is an untenable situation that makes introducing vim through this plugin to new people impossible. No one takes a plugin that breaks VS Code’s ctrl+p seriously. If this isn’t fixed by the maintainers, hopefully the project is forked by someone who takes their work seriously.

(But now that I’m thinking about it, this commit is from april. Why did this started happening to a lot of people today?)

Version 1.26.0 includes this commit, which was released a few days ago. Prior to that the last release (at least, that I see in VSCode extension browser) is 1.25.2 “6 months ago”.