UltiSnips seem to break supertab's enhanced longest matching
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
UltiSnips |
Invalid
|
Undecided
|
Unassigned |
Bug Description
Hello,
i use both supertab and ultisnips in my vim setup and until now they worked fine side by side.
Recently i dived into gtk programming and began using supertab's longestenhanced feature (see :h supertab-
Unfortunately UltiSnips seems to break this feature.
Settings of my vim setup to reproduce my results:
set completeopt=
let g:SuperTabDefau
let g:SuperTabCompl
let g:SuperTabConte
let g:SuperTabLonge
let g:SuperTabLonge
Observed behavior for two cases:
in both cases i start with the following procedure:
* open file ( :newtab gtk_source.c )
* set &tags to appended file
* write part of function name (in insert mode: gtk_w )
* press <tab>
* after that the first completion is done ( 'i' is appended to 'gtk_w' => gtk_wi )
* append an additional character by hand ( type 'd' so 'gtk_wi' => 'gtk_wid')
* press <tab> again
UltiSnips disabled:
* after that the second completion is done until the longest common match ( 'gtk_wid' => 'gtk_widget_')
with the remaining possibilities shown in the drop down menu
UltiSnips enabled:
* the second entry of the completion menu is selected and is placed in the buffer ('gtk_wid' => 'gtk_widget_
-------
I disabled UltiSnips in my .vimrc with:
let g:pathogen_disabled = []
call add(g:pathogen_
-------
I appended the tags file i used for the described usecase.
-------
It would be great if this could be fixed, since both supertab's longenhanced feature and ultisnips speed up editing significantly.
Best regards and thanks for your time
Johannes
information type: | Public → Public Security |
information type: | Public Security → Public |
Thanks, this is a terrific bug report. However I am very short on time at the moment. You could help me out a lot by trying to come up with a simpler way to reproduce this bug, as there are a lot of moving parts in this one currently.
for example not needing the omnifunc (which could change at any time and would break tests) and the completion type "context" (maybe try <c-p>) would make things easier. Can you still reproduce the bug then?