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

[FaisalBudiono]

Describe the bug After updating to the latest version (v1.26.0). The default behavior for Go to File... command is not working properly. It goes to previous line instead of showing Quick Open panel. Reverting to previous version v1.25.2 fixed this issue.

To Reproduce

1. Open some project on your vscode
2. Update to the latest version (v1.26.0).
3. Open any file
4. Make sure to focus on that file
5. Press ctrl+p

The cursor will move up.

Expected behavior The Quick Open panel should be open.

Environment (please complete the following information):

• Extension (VsCodeVim) version: v1.26.0
• VSCode version: 1.82.0
• OS: Windows 10 Home with WSL Ubuntu 20.04

[ktvdev]

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
},

[0900304132]

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.

[davdmoo]

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",
      ]
    },

[jestarray]

I thought I was going nuts when this wasn't working. I noticed it works when your cursor is focused on the terminal and I was like: huh... I coulda sworn it worked while I was in editor before too! Will disable, thanks

[FaisalBudiono]

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

[adelin-b]

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

I use both. What is the solution you think ?

[0900304132]

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.normalModeKeyBindings": [ { "before": [\"\<leader>\", "a"], "commands": ["workbench.action.quickOpen"] } ]

I bind quickOpen to other key

[gregrobsonoxb]

Thank you - thought I was going a bit loopy this morning! 🙃

[hpesoj]

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",
            ]
        },
    ],

[asermax]

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.

[eduardomezencio]

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?)

[gregrobsonoxb]

Personally I've remapped Ctrl+J and Ctrl+K for navigating forward/back through the file select list. It seems more "vim-like" to me!

But each to their own method! I realise everyone will have their own customisations!

[tgenesel]

(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".

[SamHasler]

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

[piotrwalczak1]

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.

[gebi]

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
}

[tskj]

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.

[kossnocorp]

hopefully the project is forked by someone who takes their work seriously.

@tskj is so dramatic, man. You know, if someone forks it, it will never get anywhere. How about debugging and fixing it yourself instead of piling on the maintainer who's doing their work for free so you can use VS Code in Vim mode?

[tskj]

@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).

[yiding]

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.

[grosssoftware]

@yiding See response here: https://github.com/VSCodeVim/Vim/pull/8835#issuecomment-1898695143