We display the detailed info text in the preview window. Vim's preview window is
designed to display actual files, not scratch data. Our approach is to open a
temporary file, even though that file is never written. This way, all of Vim's
existing settings for the preview window (and people's configured mappings) just
work. This is also consistent with showing the documentation in the preview
window during completion.
Other plugins have more complicated functions for this (such as eclim), or
Scratch.vim, but this approach is simple and doesn't require external
dependencies or additional settings.
Tests:
This required fixing a sort-of-bug in which the mock'd Vim module was always
only set once, and could not be changed outside of the module which created it.
This meant that it wasn't easy to have arbitrary tests, because it was dependent
on the order in which the tests execute as to whether the return from
MockVimModule() was actually the one in use.
The solution was to make the mock'd vim module a singleton, and use mock's
patch decorator to assign new MagicMock() instances to those methods in the vim
module which a particular test is interested in.
Correct FixIt chunks sorting
While playing with FixIts in C++, I found the following issue. When fixing the third line in the code:
```cpp
template<int Value> struct CT { template<typename> struct Inner; };
CT<10 >> 2> ct; // expected-warning{{require parentheses}}
```
the following result is obtained:
```cpp
CT<1(0 >> 2)> ct; // expected-warning{{require parentheses}}
```
which is obviously wrong.
The issue is YouCompleteMe does not replace the chunks in the right order. It starts by adding the closing parenthesis, add one to the delta and inserts the opening parenthesis in the wrong place cause of the delta.
We actually use the expression `str(line) + ',' + str(column)` to sort the chunks by line then column whereas it should simply be `(line, column)`.
This PR fixes this issue, adds two tests which are failing in the current version, refactors the `_HandleFixitResponse` function and cleans up code.
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.
Previously we were checking if the `hook.py` file existed for the given
filetype. ycmd has an endpoint for checking if given a filetype a
semantic completer is available. To avoid redundant requests we cache
those requests for every filetype. A semantic engine cannot be added
*after* the ycmd server is started so to avoid redundant requests we
cache those requests for every filetype and we clear the cache at server
setup, in this way if we issue a `YcmRestartServer` command the server
will be setup again and if a semantic completer is available we can use
it. Should fix#1284.
This is required to allow the ycmd GetType and GetParent subcommands to echo
their reults in vim. The apporach is to display any text returned from a
subcommand in the 'message' property assuming that the command is not a known
'GoTo' command.
- OmniCompleter is now more similar to other Completers.
- CompletionRequest doesn't store start_column anymore.
- Calling BuildRequestData only once per request.
Previously, we'd just use json.dumps() to dump out JSON. By default,
ensure_ascii is set to true and non-ASCII chars are encoded as \uXXXX.
Problems seem to happen with other text in the data then not being utf8. I'm not
sure why, still can't repro. This should go away now that we explicitly build a
unicode string which we then encode as utf8.
Hopefully fixes#821.
If it takes a while to compile the user's C++ file, the YCM client/server may
run out of threads. Vim gets laggy then.
This is a stopgap measure until I think of something better.
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
This option existed so that the user can tweak it if they found the default idle
timeout too short, for instance if they leave their machine on over the weekend.
This use case is now covered by the new YcmdKeepalive system that pings ycmd
every 10 minutes as long as Vim is running. This prevents ycmd shutting down if
one leaves their Vim instance alone for a long time.
Thus the old option is useless now; ycmd now shuts down after 3 hours of
inactivity, which should only ever happen when its corresponding Vim instance
has shut down abnormally.
By default, a ThreadPoolExecutor will wait at Python interpreter shutdown for
all the threads to stop by themselves before letting the interpreter shut down.
We don't want that for the network requests thread pool, it causes a shutdown
latency if there are outstanding requests. Killing the threads in our pool is
perfectly safe so we can avoid the latency by introducing an
UnsafeThreadPoolExecutor.
It appears that the issue comes from sending a None timeout to Requests. It
seems it's a bug in Requests/urllib3. So we just pick an arbitrary long timeout
of 30s as the default.
Vim still loves to block the main GUI thread on occasion when asking for
completions... to counteract this stupidity, we enforce a hard budget of 0.5s
for all completion requests. If the server doesn't respond by then (it should,
unless something really bad happened), we give up.
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.
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.
