ctrlp.vim icon indicating copy to clipboard operation
ctrlp.vim copied to clipboard

Triggering CtrlP does not issue "BufLeave" autocommand.

Open SirVer opened this issue 10 years ago • 6 comments

This is a problem for UltiSnips. Do you have an idea why this could be?

https://github.com/SirVer/ultisnips/issues/229#issuecomment-37389889

SirVer avatar Mar 14 '14 18:03 SirVer

It's because the CtrlP buffer is opened with :noautocmd, mostly to avoid issues with plugins that do things when autocmds are triggered.

I also use UltiSnips frequently but haven't run into that. I use an older copy from last year, not sure which revision or version.

kien avatar Mar 15 '14 06:03 kien

It's because the CtrlP buffer is opened with :noautocmd, mostly to avoid issues with plugins that do things when autocmds are triggered.

that is a weird argument. That is precisely what autocommands are for and CtrlP leaves the current buffer, so it should really raise the corresponding autocommand. Not raising correct autocommands can also interfere with plugins that expect them (case in point: UltiSnips needs to terminate the current snippet when you leave the current buffer. Not doing it leads to wrong state in the plugin).

I also use UltiSnips frequently but haven't run into that. I use an older copy from last year, not sure which revision or version.

That is great that you are using it! :) The bug was introduced by a recent contribution that adds support for unmapping jumping keys when there is no snippet (so that the default mappings can be used). When the cursor moves, UltiSnips understands that it is no longer inside of the last snippet and terminates it. But since we left the buffer, iunmap will not work. That is why we also terminate snippets before leaving a buffer - but the only way to detect this is via the autocommand that CtrlP suppresses.

I had to add a dirty work around for this issue which made me a sad panda :(

SirVer avatar Mar 15 '14 10:03 SirVer

There were actually some old issues with plugins changing things expecting the match window to be a regular buffer. It's why I want it to be more invisible.

How about adding a check for the correct buffer before running the iunmap's? Someone may use :noautocmd or eventignore anytime and change to a different buffer, which will raise the same errors from UltiSnips.

kien avatar Mar 16 '14 07:03 kien

Edit: I think I misunderstood and the below isn't true because this issue is saying ctrlp doesn't use autocommands in it's match window, not the buffers its opens.

I use vim-lawrencium and I think ctrlp opening buffers with noautocmd is causing problems. lawrencium has this augroup that detects if the buffer is in a mercurial repository or not.

augroup lawrencium_detect
     autocmd!
     autocmd BufNewFile,BufReadPost *     call s:setup_buffer_commands()
    autocmd VimEnter               *     if expand('<amatch>')==''|call s:setup_buffer_commands()|endif
augroup end

I get errors because setup_buffer_commands hasn't run.

positron avatar Mar 16 '14 21:03 positron

How about adding a check for the correct buffer before running the iunmap's? Someone may use :noautocmd or eventignore anytime and change to a different buffer, which will raise the same errors from UltiSnips.

that is what I did, but it feels inelegant.

But I guess you are right, I have to blame Vim for actually offering the noautocmd - a design flaw imho, so I'll need to support people using it. My argument still stands though - a plugin should not use it, as they should not vmap (instead xmap) or normal (instead normal!). All of these are design flaws in Vim too - there should be no way of messing any of these up, but they are.

SirVer avatar Mar 17 '14 05:03 SirVer

I too am running into this issue. I know that ctrlp allows hooks for "exit", but that occurs too early. I need the BufLeave command.

jordwalke avatar Dec 27 '15 11:12 jordwalke