~dannyfreeman/jarchive#2: 
wrong-type-argument when executing org-roam find-file-hooks

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.

Example callstack

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  string-prefix-p(nil "zipfile:///home/lassemaatta/.m2/repository/org/clojure/clojure/1.11.1/clojure-1.11.1.jar::clojure/co..." nil)
  file-relative-name("zipfile:///home/lassemaatta/.m2/repository/org/clojure/clojure/1.11.1/clojure-1.11.1.jar::clojure/co..." "~/org-roam")
  org-roam-file-p()
  org-roam-db-autosync--setup-file-h()
  run-hooks(find-file-hook)
  after-find-file(nil t)
  find-file-noselect-1(#<buffer core.clj(clojure-1.11.1.jar)> "zipfile:///home/lassemaatta/.m2/repository/org/clo..." nil nil "zipfile:///home/lassemaatta/.m2/repository/org/clo..." nil)
  find-file-noselect("zipfile:///home/lassemaatta/.m2/repository/org/clo...")
  #f(compiled-function (l) #<bytecode -0x18116740c75d3c26>)(#s(xref-file-location :file "zipfile:///home/lassemaatta/.m2/repository/org/clo..." :line 1878 :column 10))
  apply(#f(compiled-function (l) #<bytecode -0x18116740c75d3c26>) #s(xref-file-location :file "zipfile:///home/lassemaatta/.m2/repository/org/clo..." :line 1878 :column 10) nil)
  xref-location-marker(#s(xref-file-location :file "zipfile:///home/lassemaatta/.m2/repository/org/clo..." :line 1878 :column 10))
  xref-pop-to-location(#s(xref-match-item :summary #("(defmacro when-let" 10 18 (face xref-match)) :location #s(xref-file-location :file "zipfile:///home/lassemaatta/.m2/repository/org/clo..." :line 1878 :column 10) :length 8) nil)
  consult-xref(#f(compiled-function () #<bytecode 0x17a9343ed7a4e2dd>) ((window . #<window 17 on core.clj>) (display-action) (auto-jump)))
  xref--show-defs(#f(compiled-function () #<bytecode 0x17a9343ed7a4e2dd>) nil)
  xref--find-definitions("LSP identifier at point" nil)
  xref-find-definitions("LSP identifier at point")
  funcall-interactively(xref-find-definitions "LSP identifier at point")
  command-execute(xref-find-definitions)
Status
RESOLVED FIXED
Submitter
~lassemaatta
Assigned to
Submitted
7 months ago
Updated
7 months ago
Labels
No labels applied.

~dannyfreeman 7 months ago

"~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

~lassemaatta 7 months ago

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!

~dannyfreeman 7 months ago

"~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

~dannyfreeman REPORTED FIXED 7 months ago

Register here or Log in to comment, or comment via email.