~dannyfreeman

Trackers

~dannyfreeman/jarchive

Last active 1 year, 2 months ago

#1 JDT URIs From jdtls 1 year, 1 month ago

Comment by ~dannyfreeman on ~dannyfreeman/jarchive

REPORTED RESOLVED WONT_FIX

#2 wrong-type-argument when executing org-roam find-file-hooks 1 year, 1 month ago

Comment by ~dannyfreeman on ~dannyfreeman/jarchive

REPORTED RESOLVED FIXED

#2 wrong-type-argument when executing org-roam find-file-hooks 1 year, 1 month ago

Comment 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 install 8c3c9fc2 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

#2 wrong-type-argument when executing org-roam find-file-hooks 1 year, 1 month ago

Comment by ~dannyfreeman on ~dannyfreeman/jarchive

"~lassemaatta" outgoing@sr.ht writes:

I was learning eglot and using jarchive to navigate to clojure libraries. I noticed that apparently org-roam installs a hook in find-file-hook to check if the file being opened is a org-roam file (org-roam-file-p), which causes problems with jarchive. When navigating to a clojure lib with xref-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, or file-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

#2 wrong-type-argument when executing org-roam find-file-hooks 1 year, 1 month ago

~dannyfreeman assigned ~dannyfreeman to #2 on ~dannyfreeman/jarchive

#1 JDT URIs From jdtls 2 years ago

Comment by ~dannyfreeman on ~dannyfreeman/jarchive

Should this functionality go in https://github.com/yveszoundi/eglot-java ??

#1 JDT URIs From jdtls 2 years ago

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)))) to eglot-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

  1. 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?)
  2. If we can determine it is eglot, can we determine the server? (We might require that eglot-extend-to-xref be enabled)
  3. 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