Omnicompletion with eclim / ScalaIDE is broken #2096
Comments
|
I suspect this is because one of the completion options contains non ASCII characters.We are working on fixes for these issues a which came with the port to Python 3. I have a branch which fixes most of them which I am working on. If you would like to try it out to see if it solves your issue there are some instructions here If not please can you enable debug logging level and re-run your test and post the output of |
|
First, updated error information: I enabled the debug logging level (the issue template should be modified to suggest this, by the way), and found a couple of exceptions. The first is this: So, it does indeed look like this is a unicode error, as you suggested. I tried to follow your instructions to see if they fix this; hopefully I did it correctly. Specifically, what I did was:
If I missed a step there, let me know. After doing those steps, the unicode error no longer appears. I do see some other weird behavior, though (perhaps I messed something up in checking out branches?). On the initial call to the semantic completion engine (by typing a |
That is normal: every event notification that we send to YCM we send it to the Identifier completer and the semantic completer, if it exists. In your case we don't have a native semantic completer for scala.
That is somewhat strange 😕 could be a bug in the way we call the
This is the best behaviour that we can get with vim (at least the last time I checked): When you do |
|
I see; I didn't realize that the So the weird behavior is just a bug with the semantic completion, and it's quite possibly just something wrong with how I checked out those particular branches of the code. If there's something specific you want me to do to try to figure that out, let me know. But at this point it's a separate issue, and one with the |
|
Thanks for the additional info, I really appreciate it!
Oops. I think I broke omnifunc completion when it returns an object rather than a list of strings. I have a feeling it might be the I'll try and debug this soon. It should be relatively easy to fix. |
|
Thanks. Can confirm I can repro this with eclim, so we'll get it fixed :) |
[READY] Fix issues with multi-byte characters ## Summary This change introduces more general support for non-ASCII characters in buffers handled by YCMD. In ycmd's public API, all offsets are byte offsets into the UTF-8 encoded buffers. We also assume (because, we have no other choice) that files stored on disk are also UTF-8 encoded. Internally, almost all of ycmd's functionality operates on unicode strings (python 2 `unicode()` and python 3 `str()` objects, transparently via `future`). Many of the downstream completion engines expect unicode code points as the offsets in their APIs. One special case is the `ycm_core` library (identifier completer and clang completer), which requires instances of the _native_ `str` type. All strings used within the c++ using `boost::python` require passing through `ToCppStringCompatible` Previously, we were largely just assuming that `code point == byte offset` - i.e. all buffers contained only ASCII characters. This worked up to a point, but more by luck than judgement in a number of places. ## References In combination with a YCM change and PR #453, I hope this: - fixes #109 - fixes ycm-core/YouCompleteMe#2096 - fixes ycm-core/YouCompleteMe#2088 - fixes ycm-core/YouCompleteMe#2069 - fixes ycm-core/YouCompleteMe#2066 - fixes ycm-core/YouCompleteMe#1378 ## Overview of changes The changes fall into the following areas: - Providing access to and conversion to/from code points and byte offsets (`request_wrap.py`) - Changing certain algorithms/features to work entirely in codepoint space when they are trying to operate on logical 'characters' within the buffer (see known issues for why this isn't perfect, but probably most of the way there) - Changing the completers to convert between the external (on both sides) and internal representations by using the shortcuts provided in `request_wrap.py` - Adding tests for each of the completers for both completions and subcommands ## Completer-specific notes Pretty much all of the completers I tested required some changes: - clang uses utf-8 and byte offsets, but had some bugs with the `GetDoc` parsing stuff - OmniSharp speaks codepoint offsets - Tern speaks codepoint offsets - JediHTTP speaks codepoint offsets - tsserver speaks codepoint offsets - gocode speaks byte offsets - racer i did not test ## Further work / Known issues - we act blissfully ignorant of the case where a unicode character consumes multiple code points (such as where there is a modifier after the code point) - when typing a unicode character, we still get an exception from `bitset` (see #453 for that fix) - the filtering and sorting system is 100% designed for ASCII only, and it is not in the scope of this PR to change that. Currently after any filtering operation, words containing non-ASCII characters are excluded. - I did not get round to testing rust using racer - there are further changes required to YouCompleteMe client (a further PR is coming for that) <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/valloric/ycmd/455) <!-- Reviewable:end -->
Issue Prelude
Please complete these steps and check these boxes (by putting an
xinsidethe brackets) before filing your issue:
Frequently Asked Questions section.
about to report and couldn't find an answer to my problem. (Example Google
search.)
vim --version.:YcmDebugInfo.:YcmToggleLogs stderr.version) I am using.
my issue. (as well as I could...)
that any help I receive is a selfless, heartfelt gift of their free time. I
know I am not entitled to anything and will be polite and courteous.
actually perform all of these steps.
Thank you for adhering to this process! It ensures your issue is resolved
quickly and that neither your nor our time is needlessly wasted.
Issue Details
I have used YCM and eclim together successfully for several years (i.e., I know how to set this up properly, and I know what it's supposed to do). Recently, however, I have noticed a problem. When getting completions in scala files, YCM will correctly display the semantic completions returned by eclim, but it will not update them with its fuzzy matching when I continue typing. For example, if I type
System.out.[pause], it will give me a correct list of completions. If I then typep(so the line looks likeSystem.out.p[pause]), I get the same list of completions, not a filtered list that's been passed through YCM's fuzzy matching. The completion dropdown redraws, so it's clearly doing something, but it just gives the same list. When completing identifiers (not semantic completions that come from eclim), or when doing semantic completions in java files, the fuzzy matching works as expected. Also, when I hit backspace when in a semantic completion context, it updates the completion list with correct fuzzy matching. If I start typing again, however, the full (unfiltered) list reappears.I can confirm that this is something introduced by an update to YCM. If I checkout commit 7fda494 (January 3, 2016), completion works as expected (that's just a randomly chosen commit because I knew this worked a few months ago). If I instead checkout commit f44435b (March 10, 2016), I see this problem. Somewhere in between those two commits, something broke. I'm happy to provide whatever else is needed to help debug the issue here.
Steps to reproduce:
I did all of these steps today, with fresh copies of everything.
sbtinstaller dependency)Then, to get working semantic completion:
~/.vim/bundle/:git clone https://github.com/Valloric/YouCompleteMe.gitcd YouCompleteMegit checkout 7fda494026b081d1f4e7bgit submodule update --init --recursive./install.pyRequested Debug output
vim --versionoutput::YcmDebugInfo::YcmToggleLogs stderr:OS: Both OS X (Yosemite) and Linux (Ubuntu 14.04, on AWS)
The text was updated successfully, but these errors were encountered: