Reduce the time spent to build the request when there are a lot of buffers by:
- using the options property on the buffer object to get the mod variable
instead of evaluating getbufvar;
- not computing the buffer filepath if the buffer is not modified;
- passing the number of the unloaded buffer instead of its filepath on the
BufferUnload event. Getting the Python buffer object from its number is
easier than from its filepath.
[READY] Fix exception when response future is not set
An `AttributeError` exception is raised when `Done` is called before `Start` in the `CompletionRequest` and `EventNotification` classes because the `_response_future` attribute is not yet defined.
Fixes#2461.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/2465)
<!-- Reviewable:end -->
Send the request as the unloaded buffer instead of the current buffer
for the BufferUnload event notification. This fixes the issue where
the filetype of the current buffer is not the same as the unloaded
buffer one, making the ycmd server uses the wrong completer when
handling the 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.
Previously, we'd implicitly turn off future notices about unknown extra conf
files if we already raised one exception about it. This breaks when the user
ends up not receiving the "unknown extra conf, load?" message.
Now we only turn off the notice as a result of the user saying "don't load this"
so that if the first request fails to reach them, they'll get a second (and
third etc) request about it.
Fixes#615
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).
The problem was that when you start vim like "vim foo.cc", the FileReadyToParse
event is sent to the server before it's actually started up. Basically, a race
condition.
We _really_ don't want to miss that event. For C++ files, it tells the server to
start compiling the file.
So now PostDataToHandlerAsync in BaseRequest will retry the request 3 times
(with exponential backoff) before failing, thus giving the server time to boot.
These happen rarely and are not a big deal when they do. We still log them to
the Vim message area, but we don't annoy the user with the default, in-your-face
Python traceback.
