UltiSnips seem to break supertab's enhanced longest matching

Bug #1084974 reported by Johannes Deutsch
6
This bug affects 1 person
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-longestenhanced) since gtk's function names are very long and often has a common beginning.

Unfortunately UltiSnips seems to break this feature.

Settings of my vim setup to reproduce my results:
   set completeopt=menu,longest
   let g:SuperTabDefaultCompletionType = 'context'
   let g:SuperTabCompletionContexts = ['s:ContextText', 's:ContextDiscover']
   let g:SuperTabContextDiscoverDiscovery = ['&omnifunc:<c-x><c-o>']
   let g:SuperTabLongestHighlight=1
   let g:SuperTabLongestEnhanced=1

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_add_accelerator')

-----------------------------------------------------

I disabled UltiSnips in my .vimrc with:

let g:pathogen_disabled = []
call add(g:pathogen_disabled, 'UltiSnips-2.2')

-----------------------------------------------------

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

Revision history for this message
Johannes Deutsch (j-deutsch) wrote :
Revision history for this message
SirVer (sirver) wrote :

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?

information type: Public → Public Security
information type: Public Security → Public
Revision history for this message
Johannes Deutsch (j-deutsch) wrote :

You had the right instinct. Commenting the line

     let g:SuperTabContextDiscoverDiscovery = ['&omnifunc:<c-x><c-o>']

let ultisnips and supertab live in harmony again.

At the moment this is quite enough for me and suffices as a workaround. Probably with respect to the current userbase this bug has very low priority for ultisnips, so chasing the bug would be out of proportion. At least from my point of view.

best regards

Revision history for this message
SirVer (sirver) wrote :

I believe that this bug might as well be posted to SuperTab because it really should not move the cursor away from the current position or disable autocommands before doing so. I close as invalid, because I believe UltiSnips is not at fault here.

Changed in ultisnips:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.