Comment by ~dannyfreeman on ~dannyfreeman/jarchive
Eglot-java package fixed this https://github.com/yveszoundi/eglot-java/issues/6
REPORTED
RESOLVED WONT_FIXComment by ~dannyfreeman on ~dannyfreeman/jarchive
REPORTED
RESOLVED FIXEDComment by ~dannyfreeman on ~dannyfreeman/jarchive
"~lassemaatta" outgoing@sr.ht writes:
Hi, and thanks for your quick response. After learning a bit about
vc-use-package
, I managed to install8c3c9fc2
and can now verify that it did indeed fix the issue. Thanks a lot!Glad to hear it works! I will have a release prepared in the next day or two, along with one other change I have needed to get around to implementing.
(See the changelog if you are interested in the other change https://git.sr.ht/~dannyfreeman/jarchive/tree/3fb68da74331c1f8160f1f3fb26e6c1a6d631f81/item/CHANGELOG.md#2023-mm-dd-0110-release-notes )
-- Danny Freeman
Comment by ~dannyfreeman on ~dannyfreeman/jarchive
"~lassemaatta" outgoing@sr.ht writes:
I was learning
eglot
and usingjarchive
to navigate to clojure libraries. I noticed that apparently org-roam installs a hook infind-file-hook
to check if the file being opened is a org-roam file (org-roam-file-p
), which causes problems withjarchive
. When navigating to a clojure lib withxref-find-definitions
the predicate calls(file-relative-name "zipfile:///home/user/.m2/repository/..::some.clj/")
which eventually throws an error.Not sure if this is an issue with
org-roam
,jarchive
, orfile-relative-name
&emacs
itself. Feel free to ping me in clojurians slack if you want to discuss this.Hello, thanks for reporting this bug!
I am unable to reproduce this directly with org-raom, but it may be because I don't know how to use and setup org-roam properly.
However, that may not be too important, as I can reproduce the error you posted and I think I have come up with a solution in this commit: https://git.sr.ht/~dannyfreeman/jarchive/commit/8c3c9fc24b62b553ee9d410bac9ca8193860f92c
Before I cut a new release of jarchive, would you mind pulling down this repository's latest main branch and testing it out locally with org-roam to see if it solves your problem?
#Thank you,
Danny Freeman
~dannyfreeman assigned ~dannyfreeman to #2 on ~dannyfreeman/jarchive
Comment by ~dannyfreeman on ~dannyfreeman/jarchive
Should this functionality go in https://github.com/yveszoundi/eglot-java ??
Ticket created by ~dannyfreeman on ~dannyfreeman/jarchive
JDTls returns a proprietary URI and expects clients to use a language extension to view contents of compiled class files in jars.
Steps to reproduce
- Install latest jdtls jdt-snapshots
- Add
(java-mode . ("jdtls" :initializationOptions (:extendedClientCapabilities (:classFileContentsSupport t))))
toeglot-server-programs
- clone groot
- cd groot && mvn compile
- visited groot/src/main/java/org/jlab/groot/math/F1D.java
- pressed M-. on
Expression
at line 23- Observe the failure
Relevant eglot event buffer logs
(:jsonrpc "2.0" :id 8 :method "textDocument/definition" :params (:textDocument (:uri "file:///home/user/dev/groot/src/main/java/org/jlab/groot/math/F1D.java") :position (:line 22 :character 4))) [server-reply] (id:8) Sun Nov 13 13:37:57 2022: (:jsonrpc "2.0" :id 8 :result [(:uri "jdt://contents/exp4j-0.4.4.jar/net.objecthunter.exp4j/Expression.class?=groot/%5C/home%5C/user%5C/.m2%5C/repository%5C/net%5C/objecthunter%5C/exp4j%5C/0.4.4%5C/exp4j-0.4.4.jar=/maven.pomderived=/true=/=/javadoc_location=/jar:file:%5C/home%5C/user%5C/.m2%5C/repository%5C/net%5C/objecthunter%5C/exp4j%5C/0.4.4%5C/exp4j-0.4.4-javadoc.jar%5C!%5C/=/=/maven.groupId=/net.objecthunter=/=/maven.artifactId=/exp4j=/=/maven.version=/0.4.4=/=/maven.scope=/compile=/=/maven.pomderived=/true=/%3Cnet.objecthunter.exp4j(Expression.class" :range (:start (:line 24 :character 13) :end (:line 24 :character 23)))])
JDTLS expects clients to talk to a language extension, the RPC method
java/classFileContents
Can jarchive use this exetension? Do we have information about
- Who or what code triggered
find-file
or variants on the JDT uri? (Was it eglot (via xref), was it a user, was it something else?)- If we can determine it is eglot, can we determine the server? (We might require that
eglot-extend-to-xref
be enabled)- Is this something jarchive should get into? Right now there is no real knowledge of eglot or language servers, besides a patch to make things work with old eglot versions. This seems like it is in the jarchive wheelhouse though.
If those questions can be answered, I think I can make the call to jdtls and populate the buffer from jarchive. If not, maybe jdtls devs can do something on there end.
See this issue: https://github.com/eclipse/eclipse.jdt.ls/issues/2322