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.
We now make sure we don't terminate ycmd if we skipped a watchdog wakeup
time. If we skipped a check, that means the machine probably went to sleep and
the client might still actually be up. In such cases, we give it one more wait
interval to contact us before we die.
Cygwin should not call OmniSharpServer with mono
Update OmniSharpServer submodule for new client path mode parameter
Pass client path mode to OmniSharpServer on run
Previously, we'd just use json.dumps() to dump out JSON. By default,
ensure_ascii is set to true and non-ASCII chars are encoded as \uXXXX.
Problems seem to happen with other text in the data then not being utf8. I'm not
sure why, still can't repro. This should go away now that we explicitly build a
unicode string which we then encode as utf8.
Hopefully fixes#821.
If it takes a while to compile the user's C++ file, the YCM client/server may
run out of threads. Vim gets laggy then.
This is a stopgap measure until I think of something better.
When I initially released this project, I released it under my own copyright. I
have since then worked on it in my 20% time at Google (and want to continue
doing this) and my life becomes much simpler if the copyright is Google's.
From the perspective of how this project is run and managed, **NOTHING**
changes. YCM is not a Google product, merely a project run by someone who just
happens to work for Google.
Please note that the license of the project is **NOT** changing.
People sending in future pull requests will have to sign the Google
[CLA](https://developers.google.com/open-source/cla/individual) (you can sign
online at the bottom of that page) before those pull requests could be merged
in. People who sent in pull requests that were merged in the past will get an
email from me asking them to sign the CLA as well.
This is actually a clang bug that's still present upstream at the time of
writing; the module.map refers to an "anm_neon.h" file that doesn't actually
exist in the folder.
Fixes#769
This reverts commit 182848050e.
The reason we are reverting this is because removing signs in a loop causes
flicker. The only non-flicker approach is to remove all signs in a buffer with
"sign unplace buffer=<buffer-num>".
So no compatibility with other plugins for us.
If the user had a hidden buffer and a recent version of Vim, the screen would
flicker every time the user typed. This was caused by a Vim bug.
On every key press, we end up calling GetUnsavedAndCurrentBufferData(), which
calls GetBufferOption( buffer_object, 'ft' ). If the buffer_object represents a
hidden buffer, Vim would flicker.
This would happen because we'd call "buffer_object.options[ 'ft' ]" in recent
versions of Vim, and that line of code causes Vim to flicker. I don't know why.
We're extracting the 'ft' value without going through buffer_object.options, and
that works just fine.
Fixes#669.
