I get this behavior when using emacs and lsp. I assume it's clojure-lsp behavior

Clojure-lsp supports that, but clients need to opt-in

https://github.com/clojure-lsp/clojure-lsp/issues/552

Is this something that’d have to be turned on in Calva?

nope, I think if Calva is already using a vscode-language-client that supports this request, it should work already c/c @U9A1RLFNV

Calva / the lsp client lib sends this during initialization:

"workspace": {
            "fileOperations": {
                "willRename": {
                    "filters": [
                        {
                            "pattern": {
                                "glob": "**/*.{clj,cljs,cljc,cljd,edn,bb,clj_kondo}",
                                "matches": "file"
                            },
                            "scheme": "file"
                        }
                    ]
                }
            }
        },

I don’t know if that is related to supporting exactly what @U01EB0V3H39 is referring to, though.

looks correct, @U01EB0V3H39 could you share a repro project and saying exactly what you are trying to do and what you expect?

The logs between client and server might be helpful, too.

From after trying to do it.

I have a hunch this might be PEBCAC (sorry!) I might’ve at some point clicked the “don’t ask me again” box in the prompt. Does anyone happen to know the name of the key in vscode’s state where that’s set?

Ok, I managed to figure out the key after some trial and error. Unfortunately, resetting it doesn’t fix the issue. I’ve also seen it work successfully on another computer, so this appears to be localized to my setup somehow. Here’s a trace of the lsp communication when I move a file.

Hmm… should there be some other message about the changing of the namespace for the new file, @UKFSJSM38? Or would that change be included in the textDocument.text value of the textDocument/didOpen notification?

@U01EB0V3H39 It might also help to compare the above with the messages from a computer that it works on.

Here you go

That log looks correct to me

The response in the first logs show no document changes in the willRenameFiles response, but the response in the second one does. Why might clojure-lsp be sending the edits in one project but not another when a file is renamed?

A repro project might help.

Would a repro project still help if the behavior is consistent across projects on the same computer?

Hmm maybe not. Have you checked that you’re using the same version of Calva and clojure-lsp on both machines?

Calva v2.0.291, clojure-lsp 2022.07.24-18.25.43 on both. Also here’s the lsp server info on the computer where it’s not working.

I also tried blowing away my global state.vscdb and restarting vscode to see if that would fix it, it did not.

Good news! I was wrong, and it is specific to this particular repo. The cause appears to be repos with multiple projects in them. I didn’t notice before because I have quite a few of these on this particular computer. I pushed a repro repo up here: https://github.com/maxrothman/clojure-lsp-repro

@U01EB0V3H39 is the root of that repo the root of your project? if so, it won't work indeed, you need at least a deps.edn in the root to clojure-lsp understand the project as a whole, or open the specific module you want to code

clojure-lsp project itself has submodules, you can use it as example :)

For this particular project, a root deps.edn wouldn’t serve any purpose apart from getting clojure-lsp to work, since it’s really a few separate applications sharing a couple of libraries. Is there any interest in adding config that tells clojure-lsp where the root is? Or what needs to be in the root deps.edn for clojure-lsp to work? I added one that just contains an empty map, and it doesn’t seem to fix the problem.

No, this is client's responsibility tell to server what is the root when initializing. Even so, it's a good practice for toolings having something on root that bring all together for tooling. having a empty deps.edn wouldn't help since you would be ignoring the submodules deps.edn, what you can do is link the inner modules deps.edn on the root deps.edn like clojure-lsp does https://github.com/clojure-lsp/clojure-lsp/blob/master/deps.edn#L2-L5. Other libs like #polylith works similar

Adding a proper root-level deps.edn worked, thanks!

It sounds like pprint is truncating the output. You can try disabling pprint by clicking the button in the status bar at the bottom right, or you can edit your pprint settings to make it not truncate, or to truncate at a much higher value.

Although that last issue you mentioned sounds odd.

I actually found that it was turned off. I don’t have a good example to reproduce ATM, I’ll post when I see it again.

Seeing this issue again. I added a bunch of println statements to the code I’m testing. When running it by simply calling my function in repl, I only see the first println printed. When using debugging mode, stepping over these statements I get all of them printed.

I’ll try to extract a reproducible test case.

I verified that pprint option in status bar has no effect.

Looks like I found a reproducible test case:

(defn test []
  (println (with-out-str (clojure.pprint/pprint "Hello1")))
  (println (with-out-str (clojure.pprint/pprint "Hello2"))))

This one is even simpler:

(defn test []
  (println (with-out-str (clojure.pprint/pprint "Hello1")))
  (println "Hello2"))

I’m getting only

Hello1

This also reproduces the issue:

(defn test []
  (println (with-out-str (println "Hello1")))
  (println "Hello2"))

Getting this output:

clj꞉user꞉> 
(user/test)
Hello1
nil

Thanks for reporting the repro! Can you put this information in an issue?

I can’t reproduce this with the Getting Started REPL. I get this output:

clj꞉hello-repl꞉> 
Hello1

Hello2
nil

Interestingly, it also works for me today. I will still open the issue to track this in case it reproduces again: https://github.com/BetterThanTomorrow/calva/issues/2172.