Refactorings and jar definition lookups do not work on Windows

[PEZ]

I am not sure this is not related to Calva, but it seems we do things right on the client end when I look at it.

Anyway, for this example, on Windows,, definitions for remove, apply, mapv etcetera do not work. Definitions for util/add7 and for v works.

(ns pez.lab.seven-segments
  (:require [clojure.string :as string]
            [pez.util :as util]))

(comment
  (util/add7 8))

(defn transpose [v]
  (->> v
       (remove nil?)
       (apply mapv vector)))
...

Also refactorings like trying to unwind the thread on v doesn't work. It gives a warning in the log:

WARN clojure-lsp.handlers: Could not find a form at this location. ...what looks like the right location to me...

This seem somewhat covered by #25

[kstehn]

Regarding the jar definition i found in the lsp log that it cant start lein.
I then looked into the code and basicly lein classpath gets executed by the java shell.

Started my own repl and tested:
(clojure.java.shell/sh "lein" "classpath") => not found file
(clojure.java.shell/sh "which" "lein") => correct path to bin
(clojure.java.shell/sh "lein.bat" "classpath") => works as expected

[duke13137]

@kstehn, that can be fixed in .lsp/config.edn

{:project-specs [{:project-path "project.clj"
                         :classpath-cmd ["lein.bat" "classpath"]}]}

However, It seems clojure-lsp in calva use clj-kondo to scan classpath dependent jars and cache metadata in .clj-kondo/.cache, but clj-kondo doesn't seem do that either on windows.

[ericdallo]

@PEZ could you confirm @FongHou fix the issue? I wonder what we could change on clojure-lsp for a permanent fix

[duke13137]

@PEZ's workaround restored most of calva features with connected repl (autocomplete still doesn't work in comment block though).

@ericdallo, I think the fundamental problem on windows is that clj-kondo on windows does not index dependent jars from classpath path (see below screenshot). If clojure-lsp in calva depends on it, most of clojure-lsp features that rely on these metadata won't work.

My setup on windows, lein classpath only has one jar in .cpcache because windows can't handle long classpath. The full classpath is in META-INF/MANIFEST.MF. I don't think clj-kondo scan jars from there. Hence only two .json files from project src showed up .clj-kondo/.cache.

One more observation, I used to use clojure-lsp in coc-nvim running in WLS Ubuntu on the same windows laptop, I remember everyting work fine including refactoring and autocomplete features that depends on full classpath metadata. But these feature seems not avaliable in calva integrated clojure-lsp even VSCode is started from remote WSL (I verified integrated clj-kondo indeed scan all jars successfully in this case).

[ericdallo]

Sorry, but I still don't get it if it's a clj-kondo, clojure-lsp or Calva issue 🤷🏻‍♂️

[duke13137]

Things seem get complicated when all three interact with each other :-)

No worries, what's been added are still great. Thank you very much for your work!

[ericdallo]

Thanks!

Still, if we have any evidence that may be a bug on clojure-lsp I'll glad to help, let's wait for more users report, also I have no Windows to test the changes

[bpringe]

I tested this in a Windows VM and can reproduce. This is the code I'm using on both, in a windows.clj file. I put my cursor at hiccup.core in the ns require and run Go To Definition.

(ns windows
  (:require [hiccup.core :as h]))

(comment
  (h/html [:div "hello"]))

This is the request/response on Linux (working):

[Trace - 10:12:15 AM] Sending request 'textDocument/definition - (110)'.
Params: {
    "textDocument": {
        "uri": "file:///home/brandon/development/clojure-test/src/windows.clj"
    },
    "position": {
        "line": 1,
        "character": 21
    }
}


[Trace - 10:12:15 AM] Received response 'textDocument/definition - (110)' in 8ms.
Result: {
    "uri": "jar:file:///home/brandon/.m2/repository/hiccup/hiccup/1.0.5/hiccup-1.0.5.jar!/hiccup/core.clj",
    "range": {
        "start": {
            "line": 0,
            "character": 4
        },
        "end": {
            "line": 0,
            "character": 15
        }
    }
}

And this is the request/response on Windows (not working - also it's an image because not easy to copy/paste from my VM without some added effort:

[bpringe]

Both of the above are in a deps.edn project

[ericdallo]

Oh, so it looks separator issue on C:// begging parsed as C%3A/ indeed

[ericdallo]

@bpringe you may have noticed that, but Calva probably is sending the uri wrong in the request, right?