bug#58790: Eglot URI parsing bug when using clojure-lsp server

[João Távora]

Yes, i think that makes sense. Can't look at that pull request right now, but my current thinking is to leave the URI unprocessed if the scheme is anything other than file://. 

Then file-name-handler-alist can decide what to do with it.

But warning the user on such occasions sounds a bit too noisy. Maybe a one-time warning.

The only other thing to watch out for is that wherever find-file lands is, its buffer-file-name should probably be left with the unchanged URI, so that eglot--path-to-uri can return it and tell the LSP server that we're now managing the buffer using the original URI.

João

On Sat, Oct 29, 2022, 16:36 Felician Nemeth <felician.nemeth@gmail.com> wrote:

> The problem occurs when using `xref-find-defintions` while eglot is
> managing a clojure buffer with clojure-lsp. If the symbol that
> xref-find-definitions is activated on is defined in a jar file,
> clojure-lsp by default will provide a location with a response like
> the following
>
> (:jsonrpc "2.0" :id 14 :result
>   (:uri
>   "zipfile:///Users/andreperictavares/.m2/repository/org/clojure/tools.namespace/0.3.1/tools.namespace-0.3.1.jar::clojure/tools/namespace/find.clj"
> ... ))
>

Can you, please, consider merging something like github#854?
https://github.com/joaotavora/eglot/pull/854

Currently, Eglot assumes that the uri-scheme is always "file".  I think
Eglot should at least warn the user if this assumption is false instead
of silently failing as it currently does.

Thanks.