Now the user has the option of writing custom logic before ycm_core.so is
loaded. This can be used to dynamically change the location of where ycm_core.so
is loaded by prepending paths to sys.path.
Very, very few people will need this feature, but I'm one of them so there.
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.
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`.
Vim allows setting the filetype string to something like "cpp.c", which means
that the file is both cpp and c (nonsense, but allowed). We need to support such
filetype strings.
This was intended to show the full clang output for a given diagnostic,
including notes. But it appears that libclang does not provide this
functionality...
The completion text in the menu is different. We used to just show the func name
in the "main" part of the completion menu, now we show the full signature
without the return type (which is shown on the right)
This should help catch cases where the user jumps to an identifier and then
edits it in place; we want to add that new ident to the db ASAP because the user
may want to have it completed soon.
Still, we're not perfect. If the user just deletes chars with 'x' or 'd' in Vim
and therefore never even enters insert mode we are obviously not going to pick
up that identifier until the next full file sweep.
We limit the number of candidates returned to Vim to 20 and also make sure that
we are not returning any duplicate candidates. This provides a noticeable
improvement in latency.
This makes the whole plugin much faster since we now don't need to serialize and
deserialize the return values from python funcs before we can use them in Vim.
Oh God I've been waiting for something like this for so long... using this also
forces us to demand vim 7.3.584 or higher.
First off, we don't block the GUI thread anymore for ClangCompleter (that was
always temporary). Secondly, now ClangCompleter will cache the data coming from
clang so that query-based filtering of members is fast.
This change was also the root cause of the crash bug I spent two days tracking
down. The problem was that the new bool member was not added to the custom copy
ctor... since we don't really need a custom copy ctor for Result, we're going
with the compiler-provided one.
