Move PostComplete tests inside a class that defines setUp and tearDown
methods. Clean YCM object in tearDown method. This fixes the error
"OSError: [WinError 6] The handle is invalid" on Windows with
Python 3.5.
Python 3 is much stricter around mixing bytes with unicode (and by
"stricter," I mean it doesn't allow it at all) so we're making
vimsupport only return `unicode` objects (`str` on py3). The idea is
that YCM (and ycmd) internals only ever deal with unicode.
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.
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] 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.
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.
If the check for available completers isn't run because the server isn't
alive, or the check request erred or times out, don't cache the result. Only
cache valid returns.
[READY] Update notifications when ycmd server crashed
Instead of printing the last 30 lines of the `stderr` logfile if the server crashed, we tell the user to run the `:YcmToggleLogs stderr` command to check the logs.
Remove `SERVER_CRASH_MESSAGE_SAME_STDERR` message because we are always using the `stderr` logfile since PR #1753. Also, console ouput cannot be used to see the logs.
Simplify `_NotifyUserIfServerCrashed` method by using `CheckFilename` function from `vimsupport` module.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/1875)
<!-- Reviewable:end -->
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.
Previously, running postcomplete_tests.py could lead to MagicMock objects being
left around within the ycm modules. This lead to random test failures in other
modules.
Further, by using mock.patch appropriately, tests withing postcomplete_tests.py
no longer rely on mocking performed by previous tests (and can be successfully
run individually)
Set buffer filetypes for UltiSnips
Currently, only `all` snippets are displayed by YCM because UltiSnips is called without setting the buffer filetypes. See issue #1818.
This is fixed by using UltiSnips methods `reset_buffer_filetypes` and `add_buffer_filetypes`.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/1821)
<!-- Reviewable:end -->
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 -->
