Use the following strategy to extract identifiers from syntax
highlighting:
- ignore match and region: they mostly contain arguments,
syntax groups and regular expressions;
- ignore "nextgroup=" if first word and subsequent arguments
"skipempty", "skipwhite", and "skipnl";
- ignore "contained" argument if first word;
- add remaining words to the list of identifiers.
Fix a bug where the word "match" was extracted while not being a keyword
of the syntax language.
Do not convert strings to bytes but instead use plain strings to mimic
Vim buffers returning a list of byte objects on Python 2 and unicode
objects on Python 3.
Open the quickfix window to full width at the bottom of the screen with
its height set to fit all entries. This behavior can be overridden by
using the YcmQuickFixOpened autocommand.
Add a new section for autocommands in the documentation.
Update GoTo and ReplaceChunks tests.
On Python 3, evaluating a Vim expression will raise a unicode exception
if it contains an invalid sequence of bytes for the current encoding.
We can't really do anything about it because this is the way Vim and
Python 3 interact. However, we can prevent this situation to occur by
not evaluating Vim data that we have no control over: in particular,
the Vim globals. This is done by:
- adding one by one the YCM default options instead of extending the
Vim globals with them;
- only evaluating the Vim global variable names (and not their values)
when building the YCM options for the ycmd server.
Display an error message to the user depending on the status code
returned by the ycmd server.
Remove ycm_core checks in plugin/youcompleteme.vim. These checks are
now done by the ycmd server.
Do not start a separate process to check the core version but rely on
ycmd returning a specific exit code. This slightly improves the Vim
startup time.
vim.eval returns a str() object on py2, but our internal strings are all unicode().
We use vimsupport.VimExpressionToPythonType to wrap the conversion complexities.
Do not send an "event_notification" request in OnFileReadyToParse
function if server process is terminated. Otherwise, it blocks Vim
for one second or results in a traceback each time the InsertLeave,
CursorMoved, CursorHold, and BufferVisit events are triggered.
On Windows and Python 2, the full exception message from IOError
in CheckFilename will contain the filepath formatted as a unicode
string. Since the filepath is already added in the RuntimeError
message, use the strerror attribute to only display the error.
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 -->
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.
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
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.
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.
Add a new vim hook on CompleteDone. This hook is called when a
completions is selected.
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.
Executing the check_core_version.py script with SafePopen and stdin to
PIPE raises an error in Vim on Windows. Since the stdin option is only
useful when starting the ycmd server, it is only set in this case.
Another way in which the commit d768447 forced the client to wait for
the server to start was the UpdateDiagnosticNotifications call from the
FileReadyToParse which is called right after a buffer is loaded. In any
way if we don't have any previous FileReadyToParse request done for the
current file we bail out, so we we can wait for a FileReadyToParse
response to be available before asking if a completer is usable for the
current filetype.
ref: #1529
Previously we were checking if the `hook.py` file existed for the given
filetype. ycmd has an endpoint for checking if given a filetype a
semantic completer is available. To avoid redundant requests we cache
those requests for every filetype. A semantic engine cannot be added
*after* the ycmd server is started so to avoid redundant requests we
cache those requests for every filetype and we clear the cache at server
setup, in this way if we issue a `YcmRestartServer` command the server
will be setup again and if a semantic completer is available we can use
it. Should fix#1284.
This is required to allow the ycmd GetType and GetParent subcommands to echo
their reults in vim. The apporach is to display any text returned from a
subcommand in the 'message' property assuming that the command is not a known
'GoTo' command.
It appears to address numerous amount of issues, including: #812, #801, #887.
Proposed solution uses dummy sign which is placed before updating
diagnostic signs and unplaced afterwards, which eliminates any
flickering. Also, it not just unplace all, it unplaces only that marks
that are changed, so performance should not be an issue in case of many
diagnostic messages.
It's common solution that can be found in some vim plugins that manage
signatures.
Signed-off-by: Stanislav Seletskiy <s.seletskiy@gmail.com>
This commit is the YCM-client part of the support. The ycmd support is
already done.
We now need per-language identifier regexes in ycmd (see
identifier_utils.py). There's some for HTML, CSS and the generic regex
that was used for everything until now. Pull requests welcome for other
languages.
Fixes#86.
Issued here https://github.com/Valloric/YouCompleteMe/issues/1069
To reproduce:
1. Create any file with unicode character on its filename, e.g `Ω.c`
2. Open the file and start adding codes until >5 lines (i.e ycm start compiling)
3. YCM will crash due to unicode encoding error. See issue referenced above for complete log.
I love YCM's auto popup with keyword completion when power typing but
would rather not have semantic completion activate unless I really want
it to (most semantic completers are somewhat slow and sometimes end up
breaking my flow). When in API exploration mode, I don't mind having
to press C-Space to force completion and wait a bit more.
Unless I'm mistaken, the current code does not allow wildcards in the
specification of filetypes on which to disable automatic semantic
completion. This change allows the use of '*' to disable automatic
semantic completion in all files.
- OmniCompleter is now more similar to other Completers.
- CompletionRequest doesn't store start_column anymore.
- Calling BuildRequestData only once per request.
Crash handling code tried to read stderr log file, but the file can be deleted
by the server befor we get to look at it. In such a case, we post a different
error message (without the log output).
Point is we do our best to get the error output if the user doesn't have
g:ycm_server_keep_logfiles set. If we can't get the logfile, oh well. We tell
the user to set that flag if they care.
Fixes#974.
