[READY] Support FixIt and Refactor commands across multiple files
## Apply FixIt chunks across files
Previously, FixIts could only apply to the current buffer. Now we can apply FixIts across files, even if they are not currently open in the user's Vim. We obey existing configuration about how/where to open new files and apply changes in such a way as to not scribble the user's filesystem, and allow full undo history, like existing FixIt commands. Vim's python API actually makes this really quite easy.
To achieve this, we sort the chunks by filename, apply the existing logic unchanged. The only difference is that `ReplaceChunk` no longer implicitly assumes it applies to `vim.current.buffer`.
## Recognise 'FixIt' responses for any subcommand
Previously, we used the subcommand name to determine the type of response to expect. This coupled the client and the server and didn't allow us to apply FixIts for a "Refactor" command, or "GoTo" for a, theoretical "Find" command.
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.
## Other changes
The `vimsupport.OpenFilename` method needed to handle the presence of Vim swap files and the various user responses. This pushed the cyclomatic complexity over the threshold, so the code was partially obfuscated to accommodate the cyclomatic complexity gods.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/1917)
<!-- Reviewable:end -->
Additionally, we restructure subcommands section to organise by
command type.
There are now a significant number of subcommands offering quite
powerful features. A flat-list of such commands is not easy for users to
discover (citation needed). Restructured into:
- GoTo commands
- Documenation/type information commands
- FixIt/refactor commands
This has the following benefits:
- features are more discoverable to the user (due to contents page
update)
- more obvious where to add new subcommand documentation
- a place to write notes which apply to multiple commands (such as
jump lists, multi-file refactor)
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.
[READY] Simplify parse request handling
Moved file parse request handling into python, trying to simplify the overall flow, and allow easier additions of additional post handlers such as semantic token extraction.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/1905)
<!-- Reviewable:end -->
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.
[READY] Update Go documentation with GoTo subcommands
This also updates to latest ycmd. Changes that affect the client:
- update racerd;
- add GoTo support for Go completer;
- add concurrent requests for Typescript completer;
- fix issue #1953;
- add GoToReferences support for Typescript completer.
I changed the filetypes lists to be in alphabetical order, except the C-family languages.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/1965)
<!-- Reviewable:end -->
List of changes:
- update racerd;
- add GoTo support for Go completer;
- add concurrent requests for Typescript completer;
- fix issue #1953;
- add GoToReferences support for Typescript completer.
[READY] Update documentation of latest python completer
I've just wrote down the first things that came to mind. So any feedback on which part to expand or fix is appreciated. Specifically I don't know if would be useful to the user to know that JediHTTP exists and what it does. I fear that explaining would do more harm than good 😕
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/1928)
<!-- Reviewable:end -->
[READY] Fix issue in EventNotification tests
While I was reviewing PR #1905, I found an issue with the `EventNotification` tests. It's easy to reproduce. You just need to comment [this line in `python/ycm/youcompleteme.py`](https://github.com/Valloric/YouCompleteMe/blob/master/python/ycm/youcompleteme.py#L508) and run the tests. With this change, the `EventNotification` tests should fail since the second call of `ValidateParseRequest` re-raises the warning. However, tests are still passing because `assert_has_calls` does not check if a call was not made. For example, if `functionA` is called twice, both `assert_has_calls( [ functionA ] )` and `assert_has_calls( [ functionA, functionA ] )` are successful.
To fix this, we just need to check the number of calls using `call_count`. This is done by creating a subclass of `MagicMock` implementing the `assert_has_exact_calls` method and using it in tests.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/1927)
<!-- Reviewable:end -->
[READY] Implement new strategy to find the Python interpreter path
See discussion in issue #1891 for details.
Implement a new strategy to find the Python interpreter path:
- if specified, use `g:ycm_path_to_python_interpreter` option.
- on UNIX platforms, use `sys.executable` as the path to Python interpreter;
- on Windows, deduce it from `os.__file__` path (it should always be in the parent folder).
In all cases, check the version (2.6 or 2.7) of the Python interpreter path by running it.
This PR may break things. It needs thorough testing.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/1896)
<!-- Reviewable:end -->
assert_has_calls is not enough to check if a call didn't raise a
warning. We also need to check the number of calls. This is done by
creating a subclass of MagicMock implementing the
assert_has_exact_calls method.
[READY] Update get-pip.py script URL on AppVeyor
This fixes the following error on AppVeyor:
```
You're using an outdated location for the get-pip.py script, please use the one available from https://bootstrap.pypa.io/get-pip.py
```
I also changed the way `get-pip.py` is downloaded. This is now done like in the `ycmd` repository.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/1929)
<!-- Reviewable:end -->
Add missing implementation on OmniCompletionRequest
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.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/1916)
<!-- Reviewable:end -->
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.
Rename CheckPythonVersion to IsPythonVersionCorrect.
In embedders, sys.executable may contain a Vim path instead of a Python
one. To avoid starting a Vim instance in this case, we check that given
path ends with a Python 2.6 or 2.7 name using a regex.
Add tests for this regex.
