We could just remove the "dup: 1" part in the completion dict, but that would
leave the duplicate removal up to Vim which would be slow. Also, we might not
end up returning the correct number of results then.
For instance (`|` represents the cursor):
1. Buffer state: `foo.|bar`
2. A completion candidate of `zoobar` is shown and the user selects it.
3. Buffer state: `foo.zoobar|bar` instead of `foo.zoo|bar` which is what the
user wanted.
This commit resolves that issue.
It could be argued that the user actually wants the final buffer state to be
`foo.zoobar|` (the cursor at the end), but that would be much more difficult
to implement and is probably not worth doing.
Fixes#374.
By toggling the g:ycm_seed_identifiers_with_syntax option, the user can now tell
YCM to seed the identifier database with the language's keywords.
This is off by default because it can be noisy. Since the identifier completer
collects identifiers from buffers as the user visits them, the keywords that the
user cares about will already be in the database, regardless of the state of the
new option. So the only keywords added will be the ones the user is not using.
Meh. But people want it so there.
Fixes#142.
Depending on the user, the PrepareClangFlags rewrite of a few commits ago could
break users with an extra "clang: 'linker' input not used" (or similar) error
message because the compiler executable string was not removed from flags
upstream if the user prepended some flags to the output of PrepareClangFlags
before returning it to the caller of FlagsForFile.
Since the rewrite was supposed to be backwards compatible, this needs
to be handled.
It was possible to get a traceback if results[ 'flags' ] was a StringVec; the
code would try to perform results[ 'flags' ] += self.special_clang_flags and
this would then fail because the clang flags would be a Python list.
ycm_extra_conf.py files used to import clang_helpers and then use the
PrepareClangFlags function; this is now unnecessary since the logic from that
function has been moved to flags.py. The old PrepareClangFlags function is still
there (it just returns the flags it gets) for the sake of backwards
compatibility with old ycm_extra_conf.py files.
Fixes#307. Error is thrown when g:ycm_min_num_of_chars_for_completion
option is set to 0 user tries to delete an identifier which starts at
the beginning of the line.
This is for filename completion in the case of C-family include completion. The
path was being assembled incorrectly so os.isdir() was getting the wrong path
and then could not see was it a directory.
A few Completer methods that should have been forwarded to general completers
were not. This broke the identifier completer picking up the current identifier
right after it's typed in.
The issue was that AsyncCandidateRequestReady in the ultisnips completer would
always return false if there were no snippets for the current filetype, leading
to an infinite loop in CompletionsForQuery.
Fixes#270.
This was done by introducing a new ThreadedCompleter class that descends from
Completer. Both JediCompleter and FilenameCompleter descend from
ThreadedCompleter.
This implements the filename completer and introduces integration with
UltiSnips. The user will now see snippets in the completion menu. After
selecting a snippet, the user should invoke the UltiSnips trigger key
(which should be changed from the default of TAB) to trigger the snippet
expansion.
Fixes#77, Fixes#36
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.
This first version only uses the Jedi completion engine after a ".", similar to
how the ClangCompleter works. It is also entirely synchronous and blocks for
quite a while the first time it is called.
- 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.
