Recent VIM patch (8.2.4504) breaks Ctrl-P and cursor keys.

[systemmonkey42]

I apologise in advance for the poor quality of this bug report.

When using Ctrl-P on the latest VIM release build from source on github, pressing cursor keys no long work as expected.

I tested with a minimal .vimrc to ensure there was nothing conflicting in my setup;

source ~/.vim/bundle/vim-plug
plug#start('~/vim/bundle')
Plug 'ctrlpvim/ctrlp.vim'
plug#end()

Pressing Ctrl-P will open, the Ctrl-P popup window, but pressing Up or Down will break out of Ctrl-P and insert letters (A/B/C/D corresponding to which cursor key was pressed) into the buffer,. This may occur with other escape sequences but was easiest to test with cursor keys.

Using git bisect on the VIM source, I found patch 8.2.4504 added the new behaviour.

Build any version prior to 8.2.4504 and the cursor keys work as normal in Ctrl-P. Build 8.2.4504 or later, and they no longer work as expected. The cursor keys of course work normally WITHIN vim, regardless.

I am reluctant to raise it directly as a VIM bug, because raising a VIM bug to say "Ctrl-P no long works" isn't likely to get much attention.

If you could find the time to test Ctrl-P on a very recent VIM build, it would be much appreciated. You may be able to work around the change, or at least open a meaningful bug report.

Many Thanks.

[mattn]

Please give me some informations about your environment.

• Your terminal
• Your $TERM
• OS

[systemmonkey42]

OS - I always use VIM and TMUX built from source for specific features. I happened to trigger a build on a number of servers which then showed problems with cursor keys in Ctrl-P

• Ubuntu 14.04
• Ubuntu 18.04
• Ubuntu 20.04

Terminal app is PUTTY on Windows 10, TERM = xterm-256color

In tmux, TERM = tmux-256color

• Note that 14.04 doesn't support tmux-256color, so I use xterm-256color inside TMUX in that case.

All OS versions (both inside and outside of tmux) demonstrated the same issue.

In all cases, building vim from tag v8.2.4503 resolves the issue, which is what I've done in the meantime.

Many Thanks

[Shougo]

Please read this. https://github.com/vim/vim/issues/9903 I think you have mapped esc key.

[systemmonkey42]

@Shougo, Thanks for that. But as I mentioned I'm running a completely vanilla config for testing. To be absolutely sure, I created a temp linux account with almost no vim configuration;

.vimrc contains

set nocompatible
call plug#begin('~/.vim/bundle')
Plug 'ctrlpvim/ctrlp.vim'
call plug#end()

.vim contains just enough to load vim-plug and ctrlp with all defaults.

$ ls .vim
autoload  bundle
$ ls .vim/autoload/
plug.vim
$ ls .vim/bundle/
ctrlp.vim  vim-plug

There are no mappings, let alone any that mess with Esc (which I've always been careful to avoid)

[mattn]

Escape sequence of cursor keys are assigned to "^[[A" "^[[B" "^[[C" "^[[D". And Vim 8.2.4504 break the compatibility.

[systemmonkey42]

Yes, that is correct.

I've edited my local mapping to remove <Esc> from 'PrtExit()' mapping and the problem goes away, unfortunately it becomes impossible to use Esc to quickly abort Ctrl-P. (Ctrl-G still works fine though..)

I'm not sure of the correct way forward to retain the functionality of the escape key. VIM normally can tell the difference between ESC and Up/Down, but the patch seems to break that.

[systemmonkey42]

A quick test shows that as soon as you map Esc to anything, existing terminal codes which include escape as a prefix are broken.

Normally vim can tell the difference betweek Esc and Up/Down based on timeout and ttimeout.

However timeout and ttimeout no longer have an impact. Patch 8.2.4504 just breaks everything.

[systemmonkey42]

I'm happy to close this issue if you want, and move the discussion to vim/vim#9903 since I feel its definitely a VIM regression.

[Shougo]

It is not ctrlp.vim problem. It should be closed.

[systemmonkey42]

This has been fixed in Patch 8.2.4551

Thanks Bram!