Introducing :YcmToggleLogs command
Two approaches were proposed in PR #1753:
- open the stdout and stderr logfiles in Vim windows or close them if already opened: `:YcmToggleLogs`;
- open one of the logfiles in the preview window by specifying it as an argument in the command: `:YcmShowLog <stdout|stderr>`.
This PR merges both approaches by adding an optional argument (`Stdout` or `Stderr`) to the first approach. When no argument is given, both logfiles are opened (or closed if already opened).
With this approach, we cannot use the preview window because only one such window is allowed by Vim. So, we simulate it by adding properties specific to the preview window (horizontal split, height, etc.)
Since they are multiple ways to open a file in Vim, I added a generic function `OpenFilename` for this. It makes easy to customize the way logfiles are opened and could be useful for new features.
Tests were a pain to add and I am not sure of the way I implemented them. If someone could review them. There is some refactoring of the Vim mock.
I updated the documentation and the contribution guidelines. I added a new instruction when creating an issue: adding the output of the `:YcmDebugInfo` command. We often ask it in the issues.
I suggest fetching the `ycm-toggle-logs` branch of my repository to test yourself this command.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/1760)
<!-- Reviewable:end -->
If already opened logfiles are not visible (hidden buffers or in another
tab), close them and open new ones. It fixes the issue where the command
seems to do nothing even though it actually close the non-visible logfiles.
Mock buffers as a list of buffers where each buffer is represented
as a dictionary containing its filename, its number, and optionally
its associated window.
Test buffer visibility instead of existence.
Mock Vim wipeout command.
Refactor Vim mocks.
Run tests on OS X
There should be no difference between the behaviour on OS X and the behaviour on other platforms as all of the tests are python. However, running them is cheap and proves that there are no differences.
The approach is to import the scripts from `ycmd` with a couple of modifications:
- don't set `YCM_CORES=1` as we didn't before, and this makes the build a lot faster
- don't install `gcc-4.8` as we didn't before
- install `argparse` for the tests as it is not available in python2.6
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/1762)
<!-- Reviewable:end -->
We import the scripts from ycmd with a couple of modifications:
- don't set YCM_CORES=1 as we didn't before, and this makes the build a lot faster
- don't install gcc-4.8 as we didn't before
- install argparse as it is not available in python2.6
Fix AppVeyor configuration
AppVeyor certainly made some changes to their infrastructures because the `run_tests.py` script is not properly executed anymore. We now need to specifically call it with python.
This is already done in the `ycmd` repository so no changes needed there.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/1761)
<!-- Reviewable:end -->
Remove g:ycm_server_use_vim_stdout option
The `g:ycm_server_use_vim_stdout` option is not working like expected. ycmd logs are not written to the console when using the gui client with this option enabled. This is the case on Windows and I think @puremourning can confirm this on other platforms. Worse, it also makes the ycmd server unresponsive on Windows.
It's a big issue because we recommend to use this option in [CONTRIBUTING.md](https://github.com/Valloric/YouCompleteMe/blob/master/CONTRIBUTING.md).
This PR removes the option and updates the contribution guidelines by asking the user to put the `let g:ycm_server_keep_logfiles = 1` option instead.
To further improve the debugging process, I would like to add a new command `:YcmToggleLogs` (thanks to @puremourning for the idea) that automatically open or close the ycmd stdout and stderr logs as windows in Vim. If you agree, I'll send another PR adding the command.
Note: if you are wondering why the ycmd stdout logs are always empty while you are adding print statements in the ycmd code, this is because the output needs to be flushed: `sys.stdout.flush()`.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/1753)
<!-- Reviewable:end -->
Add an entry for Fedora installation in README.md
Following PR #1740. Update the Vim documentation.
Maybe we should remove the `super-quick` in the titles to make them shorter and be consistent with the others. I'll update the PR if you agree.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/1742)
<!-- Reviewable:end -->
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.
