omnifunc not respecting findstart when word break present

[TaDaa]

Hi and thank you for this wonderful plugin.

I have run into an issue where the completion returned from an omnifunc is not respecting the findstart value (only occuring when omnicomplete is triggered when the cursor has moved)

My target for this completion is a variation of html and that follows a special pattern that requires the colon as part of the tag. Example below. I don't want to separate the before and after parts of the colon because it would be more efficient (typing wise) not to.

<pefix:suffix

my findstart returns 0, however if I type <prefix: from the above, the completion menu aligns itself at the colon. If I manually trigger the omnifunc (C-X C-O) everything works as expected. If I override the the function below so that 0 is returned as the findstart , everything works as expected :

function! youcompleteme#Complete( findstart, base )
  " After the user types one character after the call to the omnifunc, the
  " completefunc will be called because of our mapping that calls the
  " completefunc on every keystroke. Therefore we need to delegate the call we
  " 'stole' back to the omnifunc
  if s:omnifunc_mode
    return youcompleteme#OmniComplete( a:findstart, a:base )
  endif

  if a:findstart
    " InvokeCompletion has this check but we also need it here because of random
    " Vim bugs and unfortunate interactions with the autocommands of other
    " plugins
    if !s:cursor_moved
      " for vim, -2 means not found but don't trigger an error message
      " see :h complete-functions
      return -2
    endif

    if !pyeval( 'ycm_state.IsServerAlive()' )
      return -2
    endif
    py ycm_state.CreateCompletionRequest()
    return pyeval( 'base.CompletionStartColumn()' )
  else
    return s:GetCompletions()
  endif
endfunction

[TaDaa]

Could be going down the wrong path here, but I think what I need is in the FILETYPE_TO_IDENTIFIER_REGEX -- if I could specify a custom matcher here things would be wonderful.

Also just a quick note - I tried adding ':' to the semantic completion triggers, but the cursor moved trigger seems to take priority in this scenario.

[vheon]

I just did a simple test and all works as I expect but I don't know If I understand you correctly, so see CONTRIBUTING.md and post a reproducible example with the output and the expected behaviour. Closing till then.

[TaDaa]

Made a simple test case that demonstrates the problem:

1. Create the following file

ftdetect/test.vim

au BufNewFile,BufRead *.test set ft=test
au! fileType test set omnifunc=TestCompleter
function! TestCompleter(findstart,base) 
    if a:findstart
        return 1
    endif
    return [{"abbr":"test1:test1","word":"test1:test1"},{"abbr":"test2:test2","word":"test2:test2"{"abbr":"test3:test3","word":"test4:test4"},{"abbr":"test4:test4","word":"test5:test"}]
endfunction

2. Add the following to your vimrc:

let g:ycm_semantic_triggers = {
\   'test' : ['<','>',':'] 
\ }

Just a note - I added ':' here because without it the list becomes empty

3. Restart vim
4. Enter command set ft=test
5. Go into insert mode and type >test: . The completion menu should be aligned at the 1 column, but instead it is aligned at the colon and tab completions also insert at the wrong column.

Here is a screenshot:

My expectation would be that the completion would align to the column returned by the omnifunc

[vheon]

Ok now I understand what you are talking about.

Could be going down the wrong path here, but I think what I need is in the FILETYPE_TO_IDENTIFIER_REGEX -- if I could specify a custom matcher here things would be wonderful.

First let me tell you that this was the wrong path. The FILETYPE_TO_IDENTIFIER_REGEX is for (as the name suggested) the identifier-based completion engine which do not have anything to do when you use a semantic engine, which in your case would be an omnifunc.

Having said that, I can reproduce this obviously because you were right in the title of the issue: YCM do not care for the actual result of the call to the omnifunc searching for the startfind column. You can see it at omni_completer.py#L72: the omnicompleter call the omnifunc for the startfind and check only if it returns a valid column. Then it uses the one that YCM itself calculated. I don't really know why it works like that but @Valloric must have had his own valid reason I believe (he is the only one that can answer this question).

Anyway I think that you could use the basic identifier-based engine since having a : inside a html tag is a standard thing and the FILETYPE_TO_IDENTIFIER_REGEX map has the right regexp for html tag.

[TaDaa]

Any chance we can reopen this.

This is likely an issue for all custom file types that use omnifuncs that don't adhere to the same word break rules that are being followed in YCM -- to workaround it, I would need to offer a compatibility setting for YCM that breaks the "word" string on semicolons.

[vheon]

If you want to hear from @Valloric I can reopen this.

[micbou]

Fixed by PR #2489.

[blayz3r]

I believe there is till an issue with R completion. I sometimes get the the error below on semantic completion.

When it works the trigger is not consumed i.e if completion is triggered by the dot there is an extra dot at the end.

[micbou]

@blayz3r Which plugin is providing the omnifunc?

[blayz3r]

@micbou Sorry it's https://github.com/jalvesaq/Nvim-R
Similar to #2285

[micbou]

@blayz3r PR #3117 should fix the second issue. It may also fix the first one but I can't reproduce so I am not sure.

[blayz3r]

@micbou Thanks will test after it is merged.

[micbou]

@blayz3r Can you confirm both issues are fixed?

[blayz3r]

Hi @micbou, I tested it and it works now!!! Thank you!