YCM Not using existing Omnifunc completion

[Zemnmez]

Is it possible to force this?

[SavageMessiah]

Did you get this to work? I'm using vim-fireplace and YCM seems to be ignoring the omnicompletion for that as well.

Ok, that's odd. It works if I ctrl-space but the completion while typing just skips over omni and goes to user defined.

[Zemnmez]

I realised that the omnifunc I was using (gocode) actually just doesn't work in this specific scenario. It works on saved files and functions imported from saved files.

[xelxebar]

Reviving an old thread here, but I'm experiencing the same issue. Any progress and/or insights on how to investigate the cause? Just began using ycm, so any pointers would be much appreciated.

[vheon]

A little more info could be helpful to help you :) So the output of :version, the output of set completefunc?, the output of set omnifunc? and what filetype are you trying to complete.

[xelxebar]

As a developer myself, I grimace at my lack of detailed input. Thank you for the speedy reply, vheon.

Vim Version Info

$ vim --version VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Aug 19 2014 18:47:11) 適用済パッチ: 1-410 Compiled by Arch Linux Huge 版 without GUI. 機能の一覧 有効(+)/無効(-) +acl +farsi +mouse_netterm +syntax +arabic +file_in_path +mouse_sgr +tag_binary +autocmd +find_in_path -mouse_sysmouse +tag_old_static -balloon_eval +float +mouse_urxvt -tag_any_white -browse +folding +mouse_xterm -tcl ++builtin_terms -footer +multi_byte +terminfo +byte_offset +fork() +multi_lang +termresponse +cindent +gettext -mzscheme +textobjects -clientserver -hangul_input +netbeans_intg +title -clipboard +iconv +path_extra -toolbar +cmdline_compl +insert_expand +perl +user_commands +cmdline_hist +jumplist +persistent_undo +vertsplit +cmdline_info +keymap +postscript +virtualedit +comments +langmap +printer +visual +conceal +libcall +profile +visualextra +cryptv +linebreak +python +viminfo +cscope +lispindent -python3 +vreplace +cursorbind +listcmds +quickfix +wildignore +cursorshape +localmap +reltime +wildmenu +dialog_con +lua +rightleft +windows +diff +menu +ruby +writebackup +digraphs +mksession +scrollbind -X11 -dnd +modify_fname +signs -xfontset -ebcdic +mouse +smartindent -xim +emacs_tags -mouseshape -sniff -xsmp +eval +mouse_dec +startuptime -xterm_clipboard +ex_extra +mouse_gpm +statusline -xterm_save +extra_search -mouse_jsbterm -sun_workshop -xpm システム vimrc: "/etc/vimrc" ユーザ vimrc: "$HOME/.vimrc" 第2ユーザ vimrc: "~/.vim/vimrc" ユーザ exrc: "$HOME/.exrc" 省略時の $VIM: "/usr/share/vim" コンパイル: gcc -c -I. -Iproto -DHAVE_CONFIG_H -D_FORTIFY_SOURCE=2 -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
リンク: gcc -L. -Wl,-O1,--sort-common,--as-needed,-z,relro -fstack-protector -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/core_perl/CORE -Wl,-O1,--sort-common,--as-needed,-z,relro -L/usr/local/lib -Wl,--as-needed -o vim -lm -lncurses -lelf -lnsl -lacl -lattr -lgpm -ldl -L/usr/lib -llua -Wl,-E -Wl,-rpath,/usr/lib/perl5/core_perl/CORE -Wl,-O1,--sort-common,--as-needed,-z,relro -fstack-protector -L/usr/local/lib -L/usr/lib/perl5/core_perl/CORE -lperl -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc -L/usr/lib/python2.7/config -lpython2.7 -lpthread -ldl -lutil -lm -Xlinker -export-dynamic -lruby -lpthread -lgmp -ldl -lcrypt -lm -L/usr/lib

Completion Function Info

:set completefunc? completefunc=youcompleteme#Complete

:set omnifunc? omnifunc=fireplace#omnicomplete

[vheon]

So you are trying to autocomplete clojure code? And forcing the autocompletion with <C-Space> didn't work?

[xelxebar]

Clojure code, yes.

I'm experiencing the same issue that @SavageMessiah mentions above: straight typing provides completions only for locally defined tokens; however, pressing <C-space> correctly provides omnifunc completions.

The goal is to to have those omnifunc completions appear realtime as I type without having to <C-space> it.

Somehow it feels like I might just be overlooking some small settings or something? However, leafing through the YCM help pages has yet to yield me any insight so far.

[vheon]

This has been said many times in the issue tracker like #560. What you can do is trigger the omnifunc on certain characters. Check :h g:ycm_semantic_triggers you'll see that there is no trigger for clojure. I don't code in clojure so I don't know what identifier you can use.

[seantalts]

I added some triggers for Clojure to my g:ycm_semantic_triggers and it does seem to be calling the functions, but perhaps with the wrong parameters, because when I press after (str/ it shows me all the str functions (split, split-lines, etc). While typing, though, YCM brings up a list of all possible functions in the file. Any ideas why this context might be missing in the call to the omnifunc? My omnifunc is the one set by vim-fireplace, btw.

Thanks!

[vheon]

@seantalts I didn't quite understand. Can you write the expected behaviour and what you get instead?

[mschulkind]

I think I'm hitting the same issue.

verbose set omnifunc? gives:

  omnifunc=fireplace#omnicomplete
        Last set from ~/.vim/bundle/vim-fireplace/plugin/fireplace.vim

If I type (foo/ and hit <C-space> or <C-X><C-O>, I get the omnifunc completions as expected, pulled dynamically from the REPL, but I can't seem to get YCM to automatically trigger them.

This is what I tried:

let g:ycm_semantic_triggers.clojure = ['/']

And just for sanity checking, set ft? in the buffer gives:

  filetype=clojure  

I do get local token based completions, for instance if foo/bar was used elsewhere in the file, that completion is presented by YCM.

Is it possible that YCM doesn't trigger semantic completions if it thinks you're still in the middle of one token/symbol?

[mschulkind]

Just did a whole bunch more digging and it seems like omnifunc trigger is likely just broken. I don't have any other filetypes set up to test with, but very screwy for clojure at least.

For the following line:

    foo

If I set:

let g:ycm_semantic_triggers.clojure = ['f']

PreparedTriggers._RegexTriggerMatches gets called with a start_column of 4 (1-indexed it seems, so corresponds with the 4th space character), but then the match is found at column 5, so the omnifunc doesn't get triggered.

In this situation, the following actually works:

let g:ycm_semantic_triggers.clojure = [' ']

But this is clearly not the correct use of this setting and breaks in other situations.

I'm not entirely clear what is intended here since the documentation is a little vague on what g:ycm_semantic_triggers, but my best guess is that PreparedTriggers._RegexTriggerMatches should actually be checking if match.end() is between start_column and the current cursor column.

Even if this is fixed, it seems for clojure at least, the omnifunc is fast enough that it should always be considered as a source of completions. In fact, the following works fairly well:

let g:ycm_semantic_triggers.clojure = ['re!.']

The problem now is that, unless the code has been loaded in the repl, simple identifiers are not candidates for completion like they would be without the above setting. It seems the ideal case here would be to force omnifunc always, but to merge with the standard set of completions. Is this possible somehow?

[vheon]

Thanks for the clarification. Probably it will be helpful for @Valloric to check this. I don't use clojure and fireplace.vim myself, so to clarify: for getting the omnifunc to work you have to load the code into the repl?

The problem now is that, unless the code has been loaded in the repl, simple identifiers are not candidates for completion like they would be without the above setting. It seems the ideal case here would be to force omnifunc always, but to merge with the standard set of completions. Is this possible somehow?

No. And it would be just a hack because the default behaviour seems to be broken for clojure somehow, so I think that would be better if we fix this instead.

[mschulkind]

Well, yes, it would be nice to fix the default behavior, but I don't think that will ever be the ideal for clojure. You can import symbols into the current namespace in a way that doesn't need a namespace prefix, so you can't always know from just looking at the symbol you are typing if you should be searching the REPL.

For instance, you could require namespace foo which means you'd have to type foo/bar, but you can use the namespace and then just type bar, so just looking for a / doesn't quite cover all cases.

I imagine the reason why omnifunc isn't always called is for performance reasons, but the fireplace omnifunc calls through to a clojure REPL and the completions are super fast, so even turning off omnifunc caching and using my above hack doesn't slow anything down.

I bit more experimenting reveals that even if the latest code is loaded into the repl, still omnifunc won't return all relevant completions, so being able to always call omnifunc and merge with the normal completions would really be the ideal solution for clojure.

[vheon]

We have different vision on how to use this tool (maybe because we work with different languages). When I type, usually I want tokens that I have in my open buffers so those are given to me by the regular identifier-based engine. If I want something extra, like the member functions of an object or some global function that require a semantic engine I usually get it for free by the g:ycm_semantic_triggers or by asking for them by <C-Space>. But I am the one who knows what should be written and what could be written in a certain file. Instead from what I get you want that every time you start typing something you want to see only the correct possible candidates. I'm not saying that is a bad thing, but from using and watching the changing done to YCM I don't think that is the use that YCM encourages. Naturally this is my opinion and is @Valloric that decide what will be the direction of YCM in this regard.

[mschulkind]

I hadn't really thought about it that much, but I could see that being a useful option as well. Seems like it should be fairly simple to offer that? I believe I read in the docs that there's already the possibility of combining multiple completion modes.

[vheon]

I believe I read in the docs that there's already the possibility of combining multiple completion modes.

Are you referring to the Ultisnips completions? Because that is really a special case.

[mschulkind]

"YCM automatically detects which completion engine would be the best in any situation. On occasion, it queries several of them at once, merges the outputs and presents the results to you."

Not sure what that's referring to.

On Sat, Jan 3, 2015 at 5:53 PM, Andrea Cedraro notifications@github.com wrote:

I believe I read in the docs that there's already the possibility of combining multiple completion modes.

Are you referring to the Ultisnips completions? Because that is really a special case.

— Reply to this email directly or view it on GitHub https://github.com/Valloric/YouCompleteMe/issues/438#issuecomment-68612884 .

[mschulkind]

https://github.com/mschulkind/ycmd/commit/fc8385b94f9a04301ee8d51a8c7763bee661b08b

The above seems to work fairly well.

[oblitum]

Just for reference (I've not gone deep in the discussion to make analysis), in a personal branch I had to cut the line up to the cursor position before passing its contents to _StringTriggerMatches or _RegexTriggerMatches.

In this personal branch I'm dealing with some novel completion where this started to become an issue for identifing regular expression triggers that contained wildcards at the end, like re!\(\s*, which didn't match if there was non-space characters in the line, after the current cursor position.

As I've seen _StringTriggerMatches was mentioned, I thought it would be appropriate to mention.

https://github.com/oblitum/ycmd/commit/6bda1bf2be435d8650ec6b76563f98cbcc53d2c4#diff-1001fefc4eadf6a856f90108e0fd9ebeR115

[mschulkind]

Interesting. I'm still not sure how this ever works no matter what the pattern is. From what I can tell, it checks to see if the match ends before the start of the current token.

That could make sense if the trigger character is not part of the token pattern, but then the wrong query gets sent to the omnifunc. On Jan 3, 2015 7:18 PM, "Francisco Lopes" notifications@github.com wrote:

Just for reference (I've not gone deep in the discussion to make analysis), in a personal branch I had too cut the line up to the cursor position before sending its contents to _StringTriggerMatches or _RegexTriggerMatches.

In this personal branch I'm dealing with some novel completion where this started to become an issue for identifing regular expression triggers that wildcards at the end, like re!(\s*, which didn't match if there was non-space character after the cursor position.

oblitum/ycmd@6bda1bf#diff-1001fefc4eadf6a856f90108e0fd9ebeR115 https://github.com/oblitum/ycmd/commit/6bda1bf2be435d8650ec6b76563f98cbcc53d2c4#diff-1001fefc4eadf6a856f90108e0fd9ebeR115

— Reply to this email directly or view it on GitHub https://github.com/Valloric/YouCompleteMe/issues/438#issuecomment-68615238 .

[wladston]

@mschulkind I agree with you, there seem to be some problem regarding the way the semantic matching works, it might be a bug in YCM. Why is this issue closed, @Valloric ? Did you see @mschulkind's message?

[cpixl]

Well, I'm having the same problem (maybe new issue should be created for the Clojure problem... maybe)

If I press <c-space>, I get the completions from omnifunc (set by vim-fireplace)... but I could not manage to set a decent triggering pattern for clojure filetypes. This is the best I got right now was re!. with let g:ycm_cache_omnifunc = 0 to allow things like routes/ to be reevaluated by the REPL with the correct context to autocomplete it correctly :)

What I desire (at least) is to complete before ( . and /. If I set [ '.', '/', '(' ] as the triggers, it doesn't work, and I'm not sure why. Any solutions or ideas?

[cpixl]

Okay, I created the #1602 for this case, maybe we can continue the conversation there :D

[Valloric]

@wladston You can see that the original issue reporter closed the issue; notifications about comments on closed issues tend be on the bottom of my to-read stack, so things can get lost. I just responded in #1602, which seems related.