It was never supposed to be licensed under the GPL since it's effectively
example code (that's also used for YCM compilation flags, but still).
No one has ever edited this file except me, Strahinja Val Markovic, and thus I
can release it into the public domain.
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.
Previously it returned an empty list. It makes mores sense to return the input
list of candidates because conceptually everything matches an empty query.
Reparse would take the clang lock and then possibly call Destroy while still
holding the lock. Destroy would try to take that same lock, and the mutex is not
recursive. Unpleasantness ensues.
I _think_ this is the root cause of #218, but I can't be sure. Such is life with
threads.
Fixes#218.
