-
-
Notifications
You must be signed in to change notification settings - Fork 24
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
Error with coc.nvim on windows #55
Comments
Can you grab a log of the JSON/LSP requests that are being sent? I have a theory that there's a URL that is being encoded by the client and not decoded by server |
The verbose mode output with JSON requests and responses:
|
Well, quite confirmed. I added (define (uri->path encoded-uri)
(define uri (uri-decode encoded-uri))
(cond
[(eq? (system-type 'os) 'windows)
;; If a file URI begins with file:// or file:////, Windows translates it
;; as a UNC path. If it begins with file:///, it's translated to an MS-DOS
;; path. (https://en.wikipedia.org/wiki/File_URI_scheme#Windows_2)
(cond
[(string-prefix? uri "file:////") (substring uri 7)]
[(string-prefix? uri "file:///") (substring uri 8)]
[else (string-append "//" (substring uri 7))])]
[else (substring uri 7)])) It seems that Magic Racket's behavior (not encoding the uri) is the incorrect one according to the spec, and that's because it was influenced by racket-langserver... (See this issue.) |
This seems to be a problem in Since VSC stores lots of metadata by string URIs, they were never able to fix the default behavior, so instead they added a toString override Magic Racket uses the toString(true) override and most other language clients don't seem to contain this incorrect encoding, hence why the issue seems to only appear in coc.nvim (which uses the faulty behavior of That all being said, we should just uri-decode anyway as it's correct to do so by the spec. |
That's shocking. I had never thought of the official implementation could be incorrect...
But wouldn't this cause potential bug between "decoding server" and "not encoding clients" since "%" is allowed in file path? |
Ah. I expected the official client to encode spaces and "%"s, but it appears to just send them as plaintext. So you're right, we shouldn't just uri-decode. I wonder how other language servers work with coc.nvim given this disparity? :/ Edit: Oops, turns out that |
It seems that not only coc.nvim but also vscode default to this. Here're their solutions. For coc.nvim an extension can be made to alter the client's behavior though. |
I just had this same error with emacs and eglot. The fix with |
I tried to use racket-langserver with coc.nvim, but it doesn't seem to work.
(I'm on windows with racket 8.0)
Log:
The incorrectly encoded colon (
%3A
) is suspicious but I couldn't find where it is produced.PS: Everything works fine for me with VSCode and Magic Racket.
The text was updated successfully, but these errors were encountered: