We simply apply the changes to each file in turn. The existing replacement
logic is unchanged, except that it now no longer implicitly assumes we are
talking about the current buffer.
If a buffer is not visible for the requested file name, we open it in
a horizontal split, make the edits, then hide the window. Because this
can cause UI flickering, and leave hidden, modified buffers around, we
issue a warning to the user stating the number of files for which we are
going to do this. We pop up the quickfix list at the end of applying
the edits to allow the user to see what we changed.
If the user opts to abort due to, say, the file being open in another
window, we simply raise an error and give up, as undoing the changes
is too complex to do programatically, but trivial to do manually in such
a rare case.
Now 'GoTo' and 'FixIt' commands don't need to start with those
prefixes. For 'FixIt' we can detect the response type by looking for
the 'fixits' entry in the response.
For 'GoTo' this is a touch harder, as there is no completely obvious
way to tell. However it is unique in this respect, so we can simply
fall back to it.
Completers returning other types of response are not supported by
this client.
OmniCompletionRequest is missing the RawResponse method, so any attempt to call
it calls the base class method instead. However, since the data structures of
this class and base class are different, this causes an error.
Vim's QuickFix lists require 1-based columns, which is what is returned
from ycmd's commands.
As noted in the comments, the Vim documentation for setqflist is
somewhat vague about this "byte offset", but it is confirmed to mean
"1-based column number" both in testing and in :help getqflist.
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.
