[READY] Fix entries in table of contents
Rename entries of `YcmCompleter subcommands` section in table of contents so that they correspond to their sections title. Add `Miscellaneous commands` missing entry.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/2011)
<!-- Reviewable:end -->
Make headings and TOC entries have the same text.
Use Title Case for TOC entries.
Add "Miscellaneous commands" and "Functions" entries.
Set "And That's not all..." heading in bold instead.
Move "Diagnostic highlighting groups" to a third-level entry.
[READY] Rewrite SetUpPython function
This PR fixes issue #1726 by moving most of SetUpPython logic to its own module and using a try-catch-else block at the end of the function. It also prevents Python backtraces in Vim (which are really annoying) for common exceptions (`RuntimeError` and `ImportError`).
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/1994)
<!-- Reviewable:end -->
[READY] Updating to latest ycmd
Still using ycmd only in py2, but at least we can use YCM with ycmd master again.
@micbou @puremourning @vheon Try to give this one a whirl on your machines since ycmd had a ton of recent changes.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/1995)
<!-- Reviewable:end -->
[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 -->
