Lsp server doesn't respond when special characters in filename or path.

[arjunkathuria]

I have been debugging why nimlsp wont work for me on windows, while works perfectly fine on linux.
what i found was, it seems to be that special characters in path/filename don't play nice with nimlsp and it doesnt respond.

I did some tests, This can be reproduced in linux also:-

• if there is a special character like # in your path / filename. it wont work.
• remove the spl character in question and it works again.

Steps to reproduce issue.

• i booted into linux
• i made a dir called code/nim/cil/zol.nim
• run lsp. runs fine, for the most part.
• make a dir with a spl character in name like code/nim/c#il/xol.nim
• run lsp. the server gets connected, lsp-log doesn't show any errors, but nothing works.

what causes this

while in the process, i found that the lsp-mode in emacs sends the request to server something like this:

lsp-request-while-no-input("textDocument/completion" (:textDocument (:uri "file:///d%3A/Code/nim/test_karax/kar.nim") :position (:line 3 :character 3) :context #<hash-table equal 1/65 0x35dfd95>))

if you see here, the uri it sends is already encoded:-
(:uri "file:///d%3A/Code/nim/test_karax/kar.nim")

^ this again gets normalized by nimlsp upon receiving, which further escapes it. d%253A.

proposed solution

stop normalizing the received urls ?
i taked to the lsp-mode guys on gitter too, if they'd send non encoded uri's ?
they said they need to stick to the spec and can't exactly just up and change it because they also work with other lsp-servers.

[PMunch]

Good catch! The URI -> filename should definitely be improved, not really sure why it isn't going through the URI module to begin with. The normalization that nimlsp does is only to resolve .. and such, which just makes for prettier paths, but it should definitely be un-escaped before this.

[PMunch]

I implemented some more proper handling of URIs in #66, could you try if this works, both on Windows, and with paths containing special characters?

[arjunkathuria]

Test results.

• i copied and built the new nimlsp file and replaced my .nimble binary with it.

• The completion seems to start on windows. it didn't have any completion before. see Note for further behaviour
• works in linux with normal path names like it did before
• server keeps crashing in a loop in linux with spl path names repeadly asks to restart and never really starts, i cant edit anyting in the emacs window until you let it die by pressing n finally to do you want to restart that server prompt

Note:- In the cases it does work (it manages to start) i can get 1 or 2 completions before i move around a little and it crashes again. after restarting the server, it seems to work for 1-2 more completions before dying again on moving around a little in the source code buffer in emacs.

it could be classified as buggy. not sure if its just a emacs thing ?

[michaelsbradleyjr]

I'm experiencing the same thing on macOS, e.g. in my *lsp-log* Emacs buffer I see:

The following file /Users/michael/.nimble/pkgs/libp2p- is missing, ignoring from the results.

The actual path is:

/Users/michael/.nimble/pkgs/libp2p-#unstable

and in my project's .nimble file it's specified as:

requires "libp2p#unstable"

[michaelsbradleyjr]

Any ideas how this can be investigated further? As @arjunkathuria suggested, it could just be an emacs thing, but it's a real pain, requiring one to manually rename directories in ~/.nimble/pkgs/ to remove e.g. #.

[michaelsbradleyjr]

Wild guess... since paths involve conversion to URIs, maybe the #... part of foo-#... is getting cut off because that part is a URI fragment/