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.
This will make it easy to use the same Candidates for both the
IdentifierCompleter and the ClangCompleter, thereby reducing memory consumption
and increasing performance.
This removes the need for a special overload for AddCandidatesToDatabase. Also,
the GetFuture function now provides a more sensible API with the list being
returned instead of accepted as an out parameter.
llvm also has a copy of gtest in its source tree. This causes cmake to bork
since it sees several different targets with the same name (gtest and
gtest_main). So we have to rename our versions of gtest and gtest_main to
something else... We're just appending _ycm now.
This will cause pain when we want to update gtest in the future from upstream,
but I don't see a better way of handling this.
The problem was that should have been using a longest common subsequence
algorithm for the "number of word boundary character matches" calculation. Our
old approach would fail for the following case:
Query: "caafoo"
Candidate1 : "acaaCaaFooGxx"
Candidate2 : "aCaafoog"
Candidate1 needs to win. This is now also a test case.
The point is that we want to prefer candidates that have the query characters
"earlier" in their text, e.g. "xxabcxxx" over "xxxxxabc" for "abc" query.
