Define Vim commands only if setup is successful
Vim commands (`YcmDebugInfo`, `YcmCompleter`, etc.) should not be defined if an error is encountered when processing the `s:SetUpPython` function. Why? Because those commands will return errors like `name 'ycm_state' is not defined`.
Note: due to an unexpected behavior, those commands work fine when libraries are found outdated. See issue #1726.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/1727)
<!-- Reviewable:end -->
Fix rare crash when trying to jump to file which has .swp
One of my coworkers found this crash today. Usually he opens a lot of gvim-s and forgets about them, and eventually one of GoToDefinition commands backfired :)
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/1732)
<!-- Reviewable:end -->
Move PathToPythonInterpreter function from ycmd to YouCompleteMe
This function contains mostly Vim-specific code and is only used in YouCompleteMe so we move it in vimsupport.py file.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/1719)
<!-- Reviewable:end -->
Allow subcommands to display information in the preview window
References
====
https://github.com/Valloric/YouCompleteMe/issues/1653
There will be some PRs coming to ycmd that will supply documentation in this format
Background
====
This adds support to YCM for displaying "detailed info" (e.g. quick-info, documentation, etc.) from a completer subcommand response. We display the info in the preview window.
Technical notes
====
Use of the preview window
----
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 (although, Vim fixes the preview window height to 3 in that case).
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.
`wincmd P` etc.
---
The approach in `vimsupport.py` of jumping around with `wincmd P` and `wincmd p` was taken pretty much directly from vim's `:help preview-window` (specifically `:help CursorHold-example`), so while ugly it is apparently the 'recommended' way.
`vim` module mocking
----
I had to change the way we were mocking the `vim` module in the tests. From the commit message:
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, imported by any
tests which require fiddling with it. This should hopefully help testing going
forwards.
I committed this separately to help review (hopefully).
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.
Add super-quick feature summary by completer
I never got time to do the larger revamp of the README.md, but I thought a super-quick summary would be useful, as I'm about to add yet-another subcommand to a bunch of completers.
Update subcommmands supported for typescript
Noticed that the subcommands supported by typescript are not listed. Updated the docs and ran
```
vim-tools/html2vimdoc.py -f youcompleteme README.md > doc/youcompleteme.txt
```
Add required namespace in C# after completing
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.
Demo:
By default, the using statement is inserted after the last using statement. If there aren't any, it's inserted before the first line. This behavior is customization by setting a function to the vim global ``g:ycm_cs_insert_namespace_function``. I implemented this in pure vimscript largely so I could provide such customization...
Caveats: vim does not provide a way to get which completion was inserted. To get this, we store the completions, hook the CompleteDone event, and check than if the preceding text matches any of the completions. This is imperfect, and sometimes matches when it shouldn't. Also, the CompleteDone event requires 7.3.598 or newer.
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.
Show docs from clang completer in preview window
Fixes https://github.com/Valloric/YouCompleteMe/issues/106
We add the detailed_info (which is the function definiton) followed by the brief comment if supplied.
I added a test for the method, which is now reasonably complex.
