emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: GNU bug Tracking System
Subject: bug#58790: closed (Eglot URI parsing bug when using clojure-lsp server)
Date: Wed, 23 Nov 2022 19:53:02 +0000

Your message dated Wed, 23 Nov 2022 19:53:17 +0000
with message-id 
<CALDnm51J2w=N1vFB27N3gZRhBaeebmsSVAqbxoCDUr=VLhAFMg@mail.gmail.com>
and subject line Re: bug#58790: Eglot URI parsing bug when using clojure-lsp 
server
has caused the debbugs.gnu.org bug report #58790,
regarding Eglot URI parsing bug when using clojure-lsp server
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
58790: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58790
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: Eglot URI parsing bug when using clojure-lsp server Date: Tue, 25 Oct 2022 17:44:22 -0400
Hello,

I am submitting 2 patches that were discussed over on eglot's github
issue tracker: https://github.com/joaotavora/eglot/issues/661

Only one of the patches is needed to solve the issue, but I wanted to
present both options.

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" ... ))

However, there is a clojure-lsp setting that the maintainers of clojure-lsp would like to make default that changes the URI format to send a response like this

(:jsonrpc "2.0" :id 14 :result
(:uri "jar:file:///Users/andreperictavares/.m2/repository/org/clojure/tools.namespace/0.3.1/tools.namespace-0.3.1.jar!clojure/tools/namespace/find.clj" ... )).

This jar format URI is a common thing used in the JVM world apparently. It is a URI that contains a nested URI. If eglot is provided this kind of URI it needs to parse it TWICE before eglot dispatches the path. If it's only parsed once then emacs ends up trying to navigate using something roughly equivalent to `(find-file "file:///path/to/jar")` which does not work. That is what the patch titled `0001-Parse-jar-scheme-URIs-in-eglot-correctly.patch` fixes.

The other patch forces clojure-lsp to use the `zipfile` scheme and avoids the need to parse the URI twice. I prefer the double parsing patch though, as I believe if other language servers for JVM languages use this jar URI scheme, they would also be able to benefit from the patch.

I have a very simple repository here that can be used to test the problem here: https://git.sr.ht/~dannyfreeman/eglot-xref-to-jar-repo/tree/main/item/src/user.clj#L4

With clojure and clojure-lsp installed, eglot activated in a buffer visiting that `user.clj` file, the issue can be recreated.

This is my first time attempting to contribute to emacs. I am actively going through the process of copyright assignment right now in case it is necessary.

Thank you,
Danny Freeman

Attachment: 0001-Initialize-clojure-lsp-with-the-zipfile-dependency-s.patch
Description: Text Data

Attachment: 0001-Parse-jar-scheme-URIs-in-eglot-correctly.patch
Description: Text Data

Attachment: OpenPGP_0x369D556E204D19D6.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


--- End Message ---
--- Begin Message --- Subject: Re: bug#58790: Eglot URI parsing bug when using clojure-lsp server Date: Wed, 23 Nov 2022 19:53:17 +0000
> type URLs, and we decided against the warning message. Is there anything
> else to do?

Not really. I think this bug is closed (in fact I think it was already, but I'm
not sure anymore). Closing it again.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]