shawncplus/phpcomplete.vim

phpcomplete.vim breaks ultisnips Forward/Backward triggers

Closed this issue · 14 comments

Problems summary

UltiSnips's ForwardTrigger and BackwardTrigger not working

Environment Information

  • OS: OSX 10.11.6
  • Vim version: 8.0.52 (MacVim)

Provide a minimal .vimrc with less than 50 lines (Required!)

set nocompatible
filetype off

execute 'source ~/.vim/bundle/vim-plug/plug.vim'
call plug#begin('~/.vim/bundle/')

Plug 'junegunn/vim-plug'

" Put your bundle below here
Plug 'lifepillar/vim-mucomplete'
Plug 'shawncplus/phpcomplete.vim'
Plug 'SirVer/ultisnips'
Plug 'honza/vim-snippets'
" Put your bundle above here

call plug#end()

syntax on
filetype plugin indent on

" Put your plugin settings below here
let g:mucomplete#enable_auto_at_startup = 1

" You can try to uncomment the following two lines to disable omni complete, everything just works.
" let g:mucomplete#chains = {}
" let g:mucomplete#chains.default = ['file', 'keyn', 'dict', 'ulti']

let g:UltiSnipsExpandTrigger="<C-J>"
let g:UltiSnipsJumpForwardTrigger="<C-J>"
let g:UltiSnipsJumpBackwardTrigger="<C-K>"
" Put your plugin settings above here

The reproduce ways from Vim starting (Required!)

  1. :e test.php or set ft=php
  2. type foreach the popup menu will show up, choose it and hit <C-J> to expand it, then you can't not use <C-J> to jump next position

Screen shot (if possible)

mucomplete

mucomplete

I also compose a new screencast

  1. You can see in the first foreach, I keep hit <C-J>, it can expand and jump without any problems. (I did not trigger any php omni complete function)
  2. In the second foreach, I typed $items and hit <C-J>, nothing happened. (When I typed items it will trigger php omni complete function)

So, we think the bug is caused by phpcomplete not mucomplete.

Reference:

lifepillar/vim-mucomplete#11
maralla/completor.vim#36

The problem happened in vim-mucomplete.vim & completor.vim, even use native omni trigger <C-X><X-O> without any third party completion plugins.

But, you may want to know one thing, the problem does not exist in YouCompleteMe & NeoComplete.

I guess they did not use phpcomplete to complete the word, they just use phpcomplete as a source to get the candidate list and use their own customized complete function to complete the word. That's why they never have this problem.

Thank you for the awesomely detaled report!

My initial guess is that the issue night be the buffer-switching that the plugin does in order to generate the results, but that would affect the other completion plugins as well. I need to look into how these bindings handled, maybe theres some buffer specific state that gets trampled.

I've tried to look into this issue. So far I've only managed to confirm that the issue arises from the fact that phpcomplete will open splits and windows in order to do it's functions. In our testcase it's done for getting the current namespace, if I return before / remove that the issue goes away.

On how or why this isn't affecting others or on how to fix it I'm not sure yet, but wanted to report back to you. What needs to be done is to figure out how to make ultisnips survive this side-effect, but I'm not intimately familiar with it's inner workings.

Thanks for your further investigation of this bug, maybe we could invite @SirVer (Author of UltiSnips) to join the discussion to see if we can fix this.

I am not maintaining UltiSnips anymore, so I will not be of much help.

That said, UltiSnips ends a snippet using a autocommand whenever the users switches windows. Not doing that is very expensive since US diffs the full buffer on each move - and if the buffer looks completely different its logic weirds out.

Hmm... Do you know if is there any way to suspend this behaviour (removing / reinstating the autocommand, or just disable its effects temporarily)? Maybe re-triggering the snippet handling from the phpcomplete plugin (sounds like a terrible hack but i'm just thinking)?

Yes, as mentioned you can run a command without triggering autocommands see :noautocmd. But I guarantee you that this is not the behavior you want. It can - and will - to a 100% CPU cycle and a completely unresponsive Vi.

I see... I think we need to figure out how the other completion plugins (YCM and NeoComplete) manage to get the results from omni completion while keeping the US behaviour intact, and maybe patch it on the mucomplete side.

@markwu: Sorry, for the long delay! I've added a branch named issue-94 that has an set eventignore = 'all' around the body of the plugin.

As far as my limited testing and the unit-tests go it seem to be solving your original issue while doesn't break the whole plugin.
I'd like to ask you to first play around it with a few days / weeks and report back to me if it's working fine or not so I can be more confident merging this.

Great thanks, I'll give it a try today, and will let know the result.

@complex857 Sorry for the late, quite busy before Lunar New Year.

I just checkout issue-94 branch to do the test, it works perfect as it should be.

Thanks for the fix.

Great, thank you for looking into it, I'll merge the changes then.