- There was a bug in not calling int() on the result of the first call to the
omnifunc.
- We need to be more resilient to badly written omnifuncs and check that the
result of the second call is a list or a dict with a list, as the vim docs say
the omnifunc should return on the second call.
One of the two fixes probably fixes#198 but since I can't repro the error, I
can't be sure.
Added the `g:ycm_autoclose_preview_window_after_insertion` option
(similar to `g:ycm_autoclose_preview_window_after_completion`).
If set, the preview window is automatically closed when the user leaves
insert mode.
VimScript is not Python so "!some_string" does not return false when some_string
is not empty (it _does_ return true when some_string _is_ empty). I of course
know this, but my fingers like to forget it from time to time.
The base class completer Inner chose the first filetype available and
would use the triggers for it.
The triggers are now chosen considering the first for the current buffer
that is supported by the current completer. If there is no intersection,
it fallsback to considering the first filetype for the buffer.
GetFiletypeCompleter would always return a omnicompleter for the first
filetype in case there was no native completer, and the lookup would
stop.
This changes that behaviour to get all possible completers and tries to
find a native one among them. If no native completer is found, it
returns the omnicompleter for the first filetypes, as it used to.
clang_completer would check if the raw value of '&ft' was one of
supported filetypes for the completer.
Vim allows for multiple filetypes with a '.' separator. A file with
ft=qt.cpp, for example, would not be supported by clang_completer even
though it was a cpp file.
This patch changes that behaviour.
We used to do this but it was unsafe, as issue #167 proves. YCM has to give
libclang an include to YCM's copy of clang system headers (again, see issue #167
for details) and those headers may not be valid for a newer libclang.
If the user really wants to user the system libclang, then he can just always
call cmake himself. The installation guide in the README goes to great lengths
to explain the simple process of building YCM "by hand".
Fixes#167.
This provides a framework for completer-writers to create
completer-specific commands. I have in mind to use this for the clang
completer to force reloading of a flags module via `:YcmCompleter reload`.
To prevent the execution of malicious code the new default is
to ask the user before a `.ycm_extra_conf.py` file is loaded.
This can be disabled using the option `g:ycm_confirm_extra_conf`.
This commit introduces a helper class `FlagsModules` that keeps track of
and caches the currently loaded modules. To introduce further criteria
for a module look at `FlagsModules.ShouldLoad`.
Also `:YcmDebugInfo` now lists the file that was used to determine
the current set of flags.
`Flags.ModuleForFile` could be used in a user-facing command that
opens the `.ycm_extra_conf.py` corresponding to the current file.
A second command could then force a reloding of this module via
`Flags.ReloadModule`.
