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.
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.
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.
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.
