Moved File parse request handling and diagnostic extraction flow into
python to simplify flow and allow easier addition of new parse request
handlers such as semantic highlighter.
Refactored base_test to patch separate vimsupport functions instead of
the whole module, and interfering the test results afterwards.
Added new tests for diagnostic sign place/unplace and error/warning
count extraction API.
Add a new vim hook on CompleteDone. This hook is called when a
completions is selected.
When forcing semantic completion with the keybind, C# completions can
return a list of importable types. These types are from namespaces which
havn't been imported, and thus are not valid to use without also adding
their namespace's import statement. This change makes YCM automatically
insert the necessary using statement to import that namespace on
completion completion. In the case there are multiple possible
namespaces, it prompts you to choose one.
Fix the following cases where the completion is not triggered for
the next typed character:
- moving vertically in insert mode,
- removing a character and entering insert mode.
Another way in which the commit d768447 forced the client to wait for
the server to start was the UpdateDiagnosticNotifications call from the
FileReadyToParse which is called right after a buffer is loaded. In any
way if we don't have any previous FileReadyToParse request done for the
current file we bail out, so we we can wait for a FileReadyToParse
response to be available before asking if a completer is usable for the
current filetype.
ref: #1529
When we enter a new buffer we need to know if the ycmd server has a
native completer for the current filetype, this means that when we start
vim we need to know if the server has a completer available for the
buffer which means that we have to wait for the server to be up and
running. To mitigate this defer the setting of the omnifunction closer
to its need which is when we enter insert mode; this should give room
for the ycmd server to start before we ask for anything or at least
should reduce the time waiting.
ref: #1529
- OmniCompleter is now more similar to other Completers.
- CompletionRequest doesn't store start_column anymore.
- Calling BuildRequestData only once per request.
When I initially released this project, I released it under my own copyright. I
have since then worked on it in my 20% time at Google (and want to continue
doing this) and my life becomes much simpler if the copyright is Google's.
From the perspective of how this project is run and managed, **NOTHING**
changes. YCM is not a Google product, merely a project run by someone who just
happens to work for Google.
Please note that the license of the project is **NOT** changing.
People sending in future pull requests will have to sign the Google
[CLA](https://developers.google.com/open-source/cla/individual) (you can sign
online at the bottom of that page) before those pull requests could be merged
in. People who sent in pull requests that were merged in the past will get an
email from me asking them to sign the CLA as well.
This gets rid of the annoying flashing (issue #669), but reverts the workaround
for a rare Vim crash bug (issue #593). We can't have both. Update to latest Vim
to not get the crash bug.
Fixes#669.
This can happen when the user inserts a candidate string like "operator[]" which
doesn't end with an identifier char. A very obscure bug, but a bug nonetheless.
This is needed so that Syntastic doesn't call :SyntasticCheck (and thus YCM
code) on file save unnecessarily. We call :SyntasticCheck ourselves often
enough.
Previously the YCM Vim client would go bonkers when ycmd crashed. Now the user
can continue using Vim just without YCM functionality.
Also added a :YcmRestartServer command to let the user restart ycmd if it
crashed. With a little luck, this will be rarely necessary.
This means we can now load just ycm_client_support (which is a much smaller
library) into Vim and ycm_core into ycmd. Since ycm_client_support never depends
on libclang.so, we never have to load that into Vim which makes things much,
much easier.
This happened when moving the cursor in normal mode. The problem was that we
were calling SyntasticCheck on every cursor move because YCM would think that
the FileReadyToParse event processing returned diagnostics... but YCM only
integrates with Syntastic for C-family files.
Fixed by only triggering SyntasticCheck in C-family files.
Now, every FileReadyToParse event returns diagnostics, if any. This is instead
of the previous system where the diagnostics were being fetched in a different
request (this caused race conditions).
There appear to be timing issues for the diag requests. Somehow, we're sending
out-of-date diagnostics and then not updating the UI when things change.
That needs to be fixed.
This is still fast & efficient because if we detect that the buffer hasn't been
changed (by examining b:changedtick), the parse doesn't proceed.
In effect, we now make sure we parse the file after every change to the buffer
as soon as that change happens. This means that compilation error feedback will
now be much, MUCH quicker.
We used to do it on buffer enter and cursor hold. Doing it on insert leave too
produces much quicker compilation error feedback when editing C-family code
because the user doesn't have to wait for the next cursor hold event.
For now, doing it just for detecting whether a change was made on move in insert
mode.
Using b:changedtick instead of our homebrew way of detecting the changed should
be both faster and more robust.
If the user forced YCM to not register itself as the Syntastic checker, we
should not be calling SyntasticCheck since that would slow down everything.
Fixes#416
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.
