Searching for "co" in CtrlP causes vim-unimpaired to start outputting `:echo "Use instead...`

[Jess Archer]

Related to #155 and #156. Not sure if this is technically an issue with CtrlP or vim-unimpaired, but a recent change to vim-unimpaired triggered the issue.

After invoking :CtrlP there is a small lag before it is fully initialised. If I begin typing my fuzzy search string during this period, CtrlP normally handles it gracefully and inserts my search string in the search field once initialized, however after a recent change in vim-unimpaired, if my search begins with "co" (such as "config"), then vim-unpaired begins outputting :echo Use instead in the CtrlP search box and once CtrlP has fully initialised it then flashes an error and closes.

I captured a recording and slowed it down because it all happens so quickly:

What you can't see is that once :CtrlP is invoked, I immediately start typing "config".

My guess would be that while CtrlP is initialising, it is in normal mode and so the vim-unimpaired map is active. I'm not sure why the echo command ends up in the search field though, but I'm guessing it's to do with how CtrlP gracefully handles the user beginning their search before the plugin is fully initialised. If I pause for a split second and allow CtrlP to fully initialise before typing my search string, then the issue does not occur.

I don't know enough about vimscript and mappings to propose a solution.

[Jess Archer]

I just found another scenario where it happens:

If I invoke :CtrlP and begin typing "appointmentcontroller", when I get to the "co", the same thing happens. If I pause after typing "appointment" and let CtrlP catch up with displaying matches, and then continue typing "controller" then it is fine.

Obviously it's not feasible to remember to pause before typing "co" in a search string.

I found a similar issue reported at ctrlpvim/ctrlp.vim/issues/447 and the author said it was not a bug in CtrlP. The user was able to get around it by configuring the plugin (sickill/vim-pasta in that case) to ignore the 'ctrlp' filetype. I cannot find a way to tell vim-unimpaired to ignore the 'ctrlp' filetype here.

[Tim Pope]

We can't "ignore" the file type because it's a global mapping. I'd call it a design flaw in ctrlp, but I can't actually reproduce it, so maybe it's just your patch level of Vim has a quirk in its handling of <nowait> (which should give ctrlp precendence).

I certainly don't see anything Unimpaired specific about this bug, other than the fact co is very common in English, and perhaps the use of getchar() makes it fail a bit more conspicuously than usual.

[Jess Archer]

Thanks for the reply @tpope

My "solution" has been to add the following autocmd:

autocmd VimEnter * unmap <silent><expr> co

All the best and thanks for all the great plugins!