-
Notifications
You must be signed in to change notification settings - Fork 2.8k
YCM was rewritten to use a client-server architecture where most of the logic is
in the ycmd server. So the magic vim module you could have previously
imported in your .ycm_extra_conf.py files doesn't exist anymore.
To be fair, importing the magic vim module in extra conf files was never
supported in the first place; it only ever worked by accident and was never a
part of the extra conf API.
But fear not, you should be able to tweak your extra conf files to continue
working by using the g:ycm_extra_conf_vim_data option. See the docs on that
option for details.
These errors are caused by building the YCM native libraries for Python 2 and trying to load them into a Python 3 process (or the other way around).
For instance, if building for Python 2 but loading in Python 3:
ImportError: dynamic module does not define init function (PyInit_ycm_core)
If building for Python 3 but loading in Python 2:
ImportError: dynamic module does not define init function (initycm_core)
Setting the g:ycm_server_python_interpreter option to force the use of a
specific Python interpreter for ycmd is usually the easiest way to solve the
problem. Common values for that option are /usr/bin/python and
/usr/bin/python3.
If the warning is ld: warning: path '/usr/lib/libpython2.7.dylib' following -L not a directory, then feel free to ignore it; it's caused by a limitation of
CMake and is not an issue. Everything should still work fine.
This is Vim's preview window. Vim uses it to show you extra information about
something if such information is available. YCM provides Vim with such extra
information. For instance, when you select a function in the completion list,
the preview window will hold that function's prototype and the prototypes of
any overloads of the function. It will stay there after you select the
completion so that you can use the information about the parameters and their
types to write the function call.
If you would like this window to auto-close after you select a completion
string, set the g:ycm_autoclose_preview_window_after_completion option to 1
in your vimrc file. Similarly, the g:ycm_autoclose_preview_window_after_insertion
option can be set to close the preview window after leaving insert mode.
If you don't want this window to ever show up, add set completeopt-=preview to
your vimrc. Also make sure that the g:ycm_add_preview_to_completeopt option
is set to 0.
In Vim, run :messages and carefully read the output. YCM will echo messages to
the message log if it encounters problems. It's likely you misconfigured
something and YCM is complaining about it.
Also, you may want to run the :YcmDebugInfo command; it will make YCM spew out
various debugging information, including the YCM and ycmd logfile paths and
the compile flags for the current file if the file is a C-family language file
and you have compiled in Clang support. Logfiles can be opened in the editor
using the :YcmToggleLogs command.
This means that libclang (which YCM uses for C-family semantic completion)
failed to pre-compile your file's preamble. In other words, there was an error
compiling some of the source code you pulled in through your header files. I
suggest calling the :YcmDiags command to see what they were.
Bottom line, if libclang can't pre-compile your file's preamble because there were errors in it, you're going to get slow completions because there's no AST cache.
If this happens when Vim automatically wraps text then it's a Vim bug that has been fixed in version 8.0.0127. Update your Vim to this version or later.
This could also be some mappings that interfere with YCM's internal ones. Make
sure you don't have something mapped to <C-p>, <C-x> or <C-u> (in insert
mode).
YCM never selects something for you; it just shows you a menu and the user has to explicitly select something. If something is being selected automatically, this means there's a bug or a misconfiguration somewhere.
This means that YCM tried to set up a key mapping but failed because you already
had something mapped to that key combination. The <blah> part of the message
will tell you what was the key combination that failed.
Look in the Options section and see if any of the default mappings conflict with your own. Then change that option value to something else so that the conflict goes away.
Your system is too old for the precompiled binaries from llvm.org. Compile
Clang on your machine and then link against the libclang.so you just produced.
See the full installation guide for help.
Look at the output of your CMake call. There should be a line in it like the
following (with .dylib in place of .so on macOS):
-- Found PythonLibs: /usr/lib/libpython2.7.so (Required is at least version "2.5")
That would be the correct output. An example of incorrect output would be the following:
-- Found PythonLibs: /usr/lib/libpython2.7.so (found suitable version "2.5.1", minimum required is "2.5")
Notice how there's an extra bit of output there, the found suitable version "<version>" part, where <version> is not the same as the version of the
dynamic library. In the example shown, the library is version 2.7 but the second
string is version 2.5.1.
This means that CMake found one version of Python headers and a different version for the library. This is wrong. It can happen when you have multiple versions of Python installed on your machine.
You should probably add the following flags to your cmake call (again, dylib
instead of so on macOS):
-DPYTHON_INCLUDE_DIR=/usr/include/python2.7 -DPYTHON_LIBRARY=/usr/lib/libpython2.7.so
This will force the paths to the Python include directory and the Python library to use. You may need to set these flags to something else, but you need to make sure you use the same version of Python that your Vim binary is built against, which is highly likely to be the system's default Python.
The error is usually encountered when compiling YCM on Centos or RHEL. The full error looks something like the following:
/usr/bin/ld: /usr/local/lib/libpython2.7.a(abstract.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
It's possible to get a slightly different error that's similar to the one above. Here's the problem and how you solve it:
Your libpython2.7.a was not compiled with -fPIC so it can't be linked into
ycm_core.so. Use the -DPYTHON_LIBRARY= CMake flag to point it to a .so
version of libpython on your machine (for instance,
-DPYTHON_LIBRARY=/usr/lib/libpython2.7.so). Naturally, this means you'll have
to go through the full installation guide by hand.
This means that the server is trying to load a version of libclang that is too
old. You need at least libclang 9.0.0. We recommend running the install.py
script without --system-libclang or downloading the latest prebuilt binaries
from llvm.org when going through the full installation
guide.
This is caused by linking a static version of libpython into ycmd's
ycm_core.so. This leads to multiple copies of the python interpreter loaded
when python loads ycmd_core.so and this messes up python's global state.
The details aren't important.
The solution is that the version of Python linked and run against must be built
with either --enable-shared or --enable-framework (on OS X).
This is achieved as follows (NOTE: for macOS, replace --enable-shared
with --enable-framework):
- When building python from source:
./configure --enable-shared {options} - When building python from pyenv:
PYTHON_CONFIGURE_OPTS="--enable-shared" pyenv install {version}
See the previous answer for how to ensure your python is built to support dynamic modules.
First, put let g:ycm_collect_identifiers_from_tags_files = 1 in your vimrc.
Make sure you are using Exuberant Ctags to produce your tags
files since the only supported tag format is the Exuberant Ctags
format. The format from "plain" ctags is NOT supported. The
output of ctags --version should list "Exuberant Ctags". See Universal
Ctags for a maintained version.
Ctags needs to be called with the --fields=+l (that's a lowercase L, not a
one) option because YCM needs the language:<lang> field in the tags output.
NOTE: Exuberant Ctags by default sets language tag for
*.h files as C++. If you have C (not C++) project, consider giving parameter
--langmap=c:.c.h to ctags to see tags from *.h files.
NOTE: macOS comes with "plain" ctags installed by default. brew install ctags will get you the Exuberant Ctags version.
Also make sure that your Vim tags option is set correctly. See :h 'tags' for
details. If you want to see which tag files YCM will read for a given buffer,
run :echo tagfiles() with the relevant buffer active. Note that that function
will only list tag files that already exist.
YCM uses completefunc completion mode to show suggestions and Vim disables
<C-U> in that mode as a "feature." Sadly there's nothing I can do about this.
Vim prevents remapping of the <C-R> key in all <C-X> completion modes
(except the <C-X><C-N>/<C-X><C-P> mode which operates in the same mode as
<C-N>/<C-P>) and YCM uses the <C-X><C-U> (completefunc) mode for
completions. This means that adding <C-R> to any of the g:ycm_key_list_*
options has no effect. You need to use another key.
YCM comes with support for UltiSnips (snippet suggestions in the popup menu),
but you'll have to change the UltiSnips mappings. See :h UltiSnips-triggers in
Vim for details. You'll probably want to change some/all of the following
options:
g:UltiSnipsExpandTrigger
g:UltiSnipsJumpForwardTrigger
g:UltiSnipsJumpBackwardTriggerFor efficiency, YCM only fetches UltiSnips snippets in specific scenarios like
visiting a buffer or setting its filetype. You can force YCM to retrieve them by
manually triggering the FileType autocommand:
:doautocmd FileTypeBecause of the identifier completion engine and subsequence-based filtering. Let's say you have many dozens of files open in a single Vim instance (I often do); the identifier-based engine then needs to store thousands (if not tens of thousands) of identifiers in its internal data-structures. When the user types, YCM needs to perform subsequence-based filtering on all of those identifiers (every single one!) in less than 10 milliseconds.
I'm sorry, but that level of performance is just plain impossible to achieve with VimScript. I've tried, and the language is just too slow. No, you can't get acceptable performance even if you limit yourself to just the identifiers in the current file and simple prefix-based filtering.
YCM needs a version of Vim with the timers feature to achieve full asynchronicity. This feature is available since Vim 7.4.1578.
YCM provides powerful new functionality like signature help by using new
features in Vim such as popup windows, and new APIs such as pum_getpos. This
requires Vim 8.1.1875 and we strongly recommend using this version or later.
Use the delimitMate plugin instead. It does the same thing without conflicting with YCM.
If you have questions about the plugin or need help, please use the ycm-users mailing list, don't create issues on the tracker. The tracker is for bug reports and feature requests.
This can be a problem on virtual servers with limited memory. A possible
solution is to add more swap memory. A more practical solution would be to force
the build script to run only one compile job at a time. You can do this by
setting the YCM_CORES environment variable to 1. Example:
YCM_CORES=1 ./install.py --clang-completer
Never use Ctrl-C in Vim.
Using Ctrl-C to exit insert mode in Vim is a bad idea. The main issue here is
that Ctrl-C in Vim doesn't just leave insert mode, it leaves it without
triggering InsertLeave autocommands (as per Vim docs). This is a bad idea and
is likely to break many other things and not just YCM.
Bottom line, if you use Ctrl-C to exit insert mode in Vim, you're gonna have a
bad time.
If pressing <esc> is too annoying (agreed, it is), we suggest mapping it to
something more convenient. On a QWERTY keyboard, a good pick for the <esc> map
is inoremap jk <Esc>. This is right on the home row, it's an incredibly rare
digraph in English and if you ever need to type those two chars in sequence in
insert mode, you just type j, then wait 500ms, then type k.
Previously, YCM would send any diagnostics it would receive from the libclang semantic engine to Syntastic for display as signs in the gutter, red squiggles etc. Today, YCM uses its own code to do that.
Using Syntastic for this was always a kludge. Syntastic assumes its "checker" plugins behave in a certain way; those assumptions have never fit YCM. For instance, YCM continuously recompiles your code in the background for C-family languages and tries to push new diagnostics to the user as fast as possible, even while the user types.
Syntastic assumes that a checker only runs on file save ("active" mode) or even less frequently, when the user explicitly invokes it ("passive" mode). This mismatch in assumptions causes performance problems since Syntastic code isn't optimized for this use case of constant diagnostic refreshing.
Poor support for this use case also led to crash bugs in Vim caused by Syntastic-Vim interactions (issue #593) and other problems, like random Vim flickering. Attempts were made to resolve these issues in Syntastic, but ultimately some of them failed (for various reasons).
Implementing diagnostic display code directly in YCM resolves all of these problems. Performance also improved substantially since the relevant code is now written in Python instead of VimScript (which is very slow) and is tailored only for YCM's use-cases. We were also able to introduce new features in this area since we're now not limited to the Syntastic checker API.
We've tried to implement this in the most backwards-compatible way possible; YCM options that control diagnostic display fall back to Syntastic options that control the same concepts if the user has those set.
Still, some Syntastic-specific configuration you might have had might not be supported by the new code. Please file issues on the tracker in such cases; if we find the request to be reasonable, we'll find a way to address it.
This is caused by an issue with libclang that only affects some operating
systems. Compiling with clang the binary will use the correct default header
search paths but compiling with libclang.so (which YCM uses) does not.
macOS is normally affected, but there's a workaround in YCM for that specific OS. If you're not running that OS but still have the same problem, continue reading.
The workaround is to call echo | clang -v -E -x c++ - and look at the
paths under the #include <...> search starts here: heading. You should take
those paths, prepend -isystem to each individual path and append them all to
the list of flags you return from your Settings function in your
.ycm_extra_conf.py file.
See issue #303 for details.
When I start vim I get a runtime error saying R6034 An application has made an attempt to load the C runtime library incorrectly.
CMake and other things seem to screw up the PATH with their own msvcrXX.dll versions. Add the following to the very top of your vimrc to remove these entries from the path.
python << EOF
import os
import re
path = os.environ['PATH'].split(';')
def contains_msvcr_lib(folder):
try:
for item in os.listdir(folder):
if re.match(r'msvcr\d+\.dll', item):
return True
except:
pass
return False
path = [folder for folder in path if not contains_msvcr_lib(folder)]
os.environ['PATH'] = ';'.join(path)
EOFNo. Both the Vim client and the ycmd server run on Python 2 or 3. If
you are talking about code completion in a project, you can configure the Python
used for your project through a .ycm_extra_conf.py file. See the Python
Semantic Completion section for more details.
On Windows I get E887: Sorry, this command is disabled, the Python's site module could not be loaded
If you are running vim on Windows with Python 2.7.11, this is likely caused by a bug. Follow this workaround or use a different version (Python 2.7.12 does not suffer from the bug).
This means that the Python used to run Jedi is not the Python of the virtual
environment you're in. To resolve this you should create a .ycm_extra_conf.py
file at the root of your project that sets the interpreter_path option to the
Python of your virtual environment, e.g.
def Settings(**kwargs):
return {
'interpreter_path': '/path/to/virtual/env/bin/python'
}See the Python Semantic Completion section for more details.
In recent versions of Vim, you can install YCM in a folder under
~/.vim/pack/*/opt and then load it once the user is idle via an autocommand:
augroup load_ycm
autocmd!
autocmd CursorHold, CursorHoldI * :packadd YouCompleteMe
\ | autocmd! load_ycm
augroup ENDYCM relies on the VimLeave event to shut down the ycmd server. Some
plugins prevent this event from triggering by exiting Vim through an autocommand
without using the nested keyword (see :h autocmd-nested). You should
identify which plugin is responsible for the issue and report it to the plugin
author. Note that when this happens, ycmd will automatically shut itself
down after 30 minutes.
Anaconda is often incompatible with the pre-built libclang used by YCM
and therefore is not supported. The recommended way to solve this is to run
/path/to/real/python install.py (for example /usr/bin/python install.py).
If you want completion in Anaconda projects, point the interpreter_path option
in your .ycm_extra_conf.py file to the path of your Anaconda Python e.g.
def Settings(**kwargs):
return {
'interpreter_path': '/path/to/anaconda/python'
}See the Python Semantic Completion section for more details.
This is a Vim bug fixed in version 8.1.0256. Update your Vim to this version or later.
Vim automatically maps the key set by the wildchar option, which is TAB by
default, to complete commands in the command-line window. If you would prefer
using this key to cycle through YCM's suggestions without changing the value of
wildchar, add the following to your vimrc:
autocmd CmdwinEnter * inoremap <expr><buffer> <TAB>
\ pumvisible() ? "\<C-n>" : "\<TAB>"