-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Completion breaks with multibyte characters #427
Comments
Sorry, I forgot to mention I'm using the latest master (4b0fc48) I don't know what you comparability requirements are for vim-lsc, but Vim somewhat recently added some multibyte-aware functions to make all of this easier, e.g.:
This requires Vim 8.2.2233 though (Dec 2020), and it'll be quite some time before e.g. Debian people will get this, but you can use e.g. Also see I couldn't really figure out the logic in |
Closes #427 Use `charcol` over `col` where it exists. Gate the function definition behind the feature check to avoid repeating it for every call.
@arp242 - Thanks for the pointer to Could you try the |
Thanks! It seems improved, but it doesn't display all completions: I checked the LSP logs, and the request and responses are completely identical for the two examples ( I tested with a clean vimrc as well. Logs for completeness sake (but I don't think this is where the problem is):
|
commit 8851e05 Author: Nate Bosch <[email protected]> Date: Wed Jun 23 18:20:09 2021 -0700 Fix cursor position following multibyte characters Closes natebosch#427 Use `charcol` over `col` where it exists. Gate the function definition behind the feature check to avoid repeating it for every call.
The following file:
Completing the
m
doesn't work in lsc. I tried VSCode, and it works there, so it seems a problem in vim-lsc rather than gopls.What it sends to
gopls
is:Putting the cursor right on top of the
m
and starting completion does work. Replacing that→
(U+2192) with e.g.>
also fixes it. So it seems it should send"character": 27
instead of"character": 29
.Looking at the LSC specification, character offsets are kinda weird:
Microsoft's love for UTF-16 strikes again 🙃
Right now it looks like it just sends the byte offset(?)
The text was updated successfully, but these errors were encountered: