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