Completion for header file name fails when typing dot

[smarttiger06]

When I inputed "#include <stdio.h>", the completing mechanism worked fine until the character ".". After the dot was typped, the completing windows disappeared.

[ghost]

Similar issue with me, except the window disappears after first letter of a header file is typed. I can not bring it back using <C-Space> either.

Here is my vim --version:

VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Jul 11 2015 19:18:40) MacOS X (unix) version Included patches: 1-769 Compiled by Homebrew Huge version with MacVim GUI. Features included (+) or not (-): +acl +file_in_path +mouse_sgr +tag_binary +arabic +find_in_path -mouse_sysmouse +tag_old_static +autocmd +float +mouse_urxvt -tag_any_white +balloon_eval +folding +mouse_xterm +tcl +browse -footer +multi_byte +terminfo ++builtin_terms +fork() +multi_lang +termresponse +byte_offset +fullscreen -mzscheme +textobjects +cindent -gettext +netbeans_intg +title +clientserver -hangul_input +odbeditor +toolbar +clipboard +iconv +path_extra +transparency +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_gui -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 +farsi +mouse_netterm +syntax system vimrc file: "$VIM/vimrc" user vimrc file: "$HOME/.vimrc" 2nd user vimrc file: "~/.vim/vimrc" user exrc file: "$HOME/.exrc" system gvimrc file: "$VIM/gvimrc" user gvimrc file: "$HOME/.gvimrc" 2nd user gvimrc file: "~/.vim/gvimrc" system menu file: "$VIMRUNTIME/menu.vim" fall-back for $VIM: "/Applications/MacVim.app/Contents/Resources/vim" Compilation: clang -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall -Wno-unknown-pragmas -pipe -DMACOS_X_UNIX -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -fno-strict-aliasing -fno-common -dynamic -g -Os -pipe -fno-common -fno-strict-aliasing -fwrapv -DENABLE_DTRACE -DMACOSX -DNDEBUG -Wall -Wstrict-prototypes -Wshorten-64-to-32 -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes -DENABLE_DTRACE -arch x86_64 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -I/System/Library/Frameworks/Tcl.framework/Headers -D_REENTRANT=1 -D_THREAD_SAFE=1 -D_DARWIN_C_SOURCE=1 Linking: clang -L. -L/usr/local/lib -L. -L/usr/local/lib -L/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config -framework CoreFoundation -lpython2.7 -L/usr/local/lib -o Vim -framework Cocoa -framework Carbon -lm -lncurses -liconv -framework Cocoa -fstack-protector -L/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE -lperl -framework Python -F/System/Library/Frameworks -framework Tcl -framework CoreFoundation -framework Ruby

Here is the error I get when I try to add a header:

Traceback (most recent call last): File "/Users/Macbook/.vim/bundle/YouCompleteMe/third_party/ycmd/third_party/bottle/bottle.py", line 861, in _handle return route.call(**args) File "/Users/Macbook/.vim/bundle/YouCompleteMe/third_party/ycmd/third_party/bottle/bottle.py", line 1734, in wrapper rv = callback(*a, **ka) File "/Users/Macbook/.vim/bundle/YouCompleteMe/third_party/ycmd/ycmd/../ycmd/watchdog_plugin.py", line 100, in wrapper return callback( *args, **kwargs ) File "/Users/Macbook/.vim/bundle/YouCompleteMe/third_party/ycmd/ycmd/../ycmd/hmac_plugin.py", line 62, in wrapper body = callback( *args, **kwargs ) File "/Users/Macbook/.vim/bundle/YouCompleteMe/third_party/ycmd/ycmd/../ycmd/handlers.py", line 101, in GetCompletions completer.ComputeCandidates( request_data ), File "/Users/Macbook/.vim/bundle/YouCompleteMe/third_party/ycmd/ycmd/../ycmd/completers/general/general_completer_store.py", line 83, in ComputeCandidates candidates += completer.ComputeCandidates( request_data ) File "/Users/Macbook/.vim/bundle/YouCompleteMe/third_party/ycmd/ycmd/../ycmd/completers/completer.py", line 166, in ComputeCandidates request_data[ 'query' ] ) File "/Users/Macbook/.vim/bundle/YouCompleteMe/third_party/ycmd/ycmd/../ycmd/completers/completer.py", line 223, in FilterAndSortCandidates ToUtf8IfNeeded( query ) ) UnicodeEncodeError: 'ascii' codec can't encode character u'\u2019' in position 19: ordinal not in range(128) 2015-07-19 10:34:07,884 - INFO - Received completion request

[puremourning]

@smarttiger06's problem is a general problem with the filename completer in most files.

I don't quite know how to fix it, but for reference I spent some time investigating, and it comes down to this (in autoload/youcompleteme.vim):

  function! s:OnCursorMovedInsertMode()                                            
    ...
    " We have to make sure we correctly leave omnifunc mode even when the user     
    " inserts something like a "operator[]" candidate string which fails           
    " CurrentIdentifierFinished check.                                             
    if s:omnifunc_mode && !pyeval( 'base.LastEnteredCharIsIdentifierChar()')       
      let s:omnifunc_mode = 0                                                      
    endif                                                                          

Basically, when you type a . in most files, YCM gets rid of the popup menu (exits omnifunc_mode) because . is not a valid 'identifier' character in the filetype. This also seems to prevent 'general' completer results from being used. This actually applies to all cases (not just #include, e.g. try completing a file whose name begins with a .).

It is certainly tricky to know how to fix this, as it is right in the core vim client stuff which is quite fiddly.

[puremourning]

for reference @Loumiakas's problem is not related to @smarttiger06's. It's more likely related to the ongoing discussions about non-ascii chars. There's another problem that the completion menu disappears when there are non-ascii chars in any filename in the completion list, but I haven't looked into that very much.

[ghost]

Well that's is the thing, I don't use non-ASCII chars at all. The error states that I have used right single quotation mark while typing out a header even though I didn't. I did a clean reinstall of Yosemite, that still didn't help. Oddly enough my macbook air with same settings and operating system has no problems like this at all.

[puremourning]

What's the output of 'set encoding?' I've seen others have a problem with this.

[ghost]

The output that I get from :encoding is UTF-8, I presume that's how it should be, right?

[ghost]

FYI, this error is a result of filename/ computer name (At least in Mac OS) containing non-ascii characters.

[milipili]

I have the same issue with the minus character in C++:

[Valloric]

Ugh, I remember noticing this bug ~2 years ago and trying to fix it. It ended up being too difficult to resolve at the time so I moved on to something else.

Like @puremourning noticed, the root of the problem is the "is this an identifier char" check in YCM. YCM doesn't know that for filename completion, the notion of allowed identifier chars should change. Teaching it to recognize completion context is... difficult, to say the least. The whole point is that YCM shouldn't know, ycmd should (and does).

With the current architecture the way it is, I'm not sure this is fixable, at least not without some really ugly hacks. To fix this once and for all, ycmd should probably return some info about the completion context that YCM could then use... something like it.

[puremourning]

This issue has been bugging me lately. It turns out either we changed something which makes my investigation above wrong, or it was just always wrong.

The issue is actually much simpler. Take for example #include <c+ (just after typing +):

• The start_column (or strictly start_codepoint) is calculated according to the c/c++ identifier chars and points to the + (as it is not an ID char)
• The clang completer is not interested in completing at this point
• The filename completer is asked if it is interested and just says no, because the check we do is that the entire string up to the start_codepoint is something like #include " or #include <.

I think the fix in this case is to just fix that check just look if start_codepoint is within something like #include <...> or #include "...". Or even to just ignore start_codepoint altogether.

I think we have similar problems for other completion contexts, but this is the one that bugs me the most, so I might have a go at fixing it.

For reference, going out of omnifunc mode doesn't cause a problem because we immediately trigger completions anyway due to the keypress.

[puremourning]

Bah, OK yes I take it all back. This is annoyingly hard to fix :(