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.
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.
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`.
Currently, when VIM opens a source file, YCM always defaults to
'g:global_ycm_extra_conf_file' if it exists.
This commit changes YCM's behaviour so that it first tries to find the config
file in the source file's folder (or any of its parents folder), before
falling back to 'g:global_ycm_extra_conf_file'.
Now there's a nice user-configurable setting for when YCM should trigger
semantic completion. This is very useful for the new omni_completer that uses
data coming from Vim's omnicomplete system.
We now use the compilation working directory for a file that is specified in the
CompilationDatabase. We don't actually change the working directory of the
process, even temporarily (that would be annoying to users); we munge the flags
coming from the database so that all the relative paths in them are resolved to
absolute ones.
