showcmd option triggers error in directory completion when directory contains file with certain non-ascii characters #2088
Comments
|
We are working on a fix for this. |
|
@mcaceresb It would be real;ly useful if you could checkout my YouCompleteMe and ycmd branches which I hope resolve this (and a number of other) unicode issues:
Feedback on whether or not it resolves your particular issue will speed up getting it PR'd :) Thanks! |
|
@puremourning This appears to fix it. The behavior now is that it lists the file with no errors raised (though it drops it after I type anything else, but I expected that). Thanks! |
|
Excellent :) |
|
@puremourning's all like: :D |
homu
added a commit
to ycm-core/ycmd
that referenced
this issue
Apr 24, 2016
[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 -->
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I have the following vimrc
I have a directory with a wile named "⌘ rest of file name" and the following text file
When I type anything after ./, I get the following
If I do
:set noshowcmdthen I can type normally (though completion for the directory does not work; of course completion still works elsewhere). Ideally completion would work but it would ignore the problematic file name. Second best would be no error message. I also have no idea why this is related to the showcmd option. My system info and vim version:The following was output by
:YcmToggleLogs stderrThe following files were pointed to me by
:YcmDebugInfostdout was blank. stderr is above. Cheers!
The text was updated successfully, but these errors were encountered: