I’ve never used that feature, but it’s supported by clojure-lsp. @UKFSJSM38 Is there anything we should do on Calva’s side to make this work?

Ah, I see what you mean now

I think clojure-lsp needs to return the location of the call site rather than the definition of the function that contains the call.

[Trace - 6:55:45 PM] Received response 'callHierarchy/incomingCalls - (183)' in 3ms.
Result: [
    {
        "from": {
            "name": "three []",
            "detail": "core",
            "kind": 12,
            "tags": [],
            "uri": "file:///Users/brandon/development/clojure-test/src/core.clj",
            "range": {
                "start": {
                    "line": 9,
                    "character": 6
                },
                "end": {
                    "line": 9,
                    "character": 11
                }
            },
            "selectionRange": {
                "start": {
                    "line": 9,
                    "character": 6
                },
                "end": {
                    "line": 9,
                    "character": 11
                }
            }
        },
        "fromRanges": []
    }
]

I didn't understand the issue, could you elaborate what clojure-lsp should send diferently?

If I double-click bar in the call hierarchy, the cursor is placed at the beginning of bar on line 7. @U02PB3ZMAHH is saying they’d like the cursor to go to foo on line 8, since the call hierarchy is for foo. In a larger function this is more helpful. You wouldn’t have to search the function body of bar to see where foo is being called.

I'm afraid this is not possible the way call hierarchy protocol works, unless there is a specific field for that, I can double check that tomorrow

I see. I just noticed that even in TypeScript projects the same behavior exists (the cursor goes to the definition of the calling function, not the call site of the function at the top of the call hierarchy being viewed).

Yeah, it's funny but vscode handles typescript differently not using LSP AFAIK :man-shrugging:

It could be something to improved on clojure-lsp, that's why I'll double check

I’m used to the this from Intellij/Cursive (evaluating) to wrap my brain around big projects

I’d jump back and forth between the caller and callee to try to get an idea of the code flow

But I don’t have enough experience with VS Code to know if there’s another way

I just found goto references Shift-F12, which looks like it will do the job

@U9A1RLFNV I confirmed the behavior and it's indeed possible to achieve that following the protocol, it's just that is not clear this behavior (probably open for other languages decide to handle that diferently), IMO we can change to this behavior as for clojure seems to makes more sense, @U02PB3ZMAHH or @U9A1RLFNV could you open an issue on clojure-lsp please?

@U02PB3ZMAHH If you could do the honors, that would be great.

@U02PB3ZMAHH @U9A1RLFNV I fixed this on clojure-lsp master!

Whoa!

@UKFSJSM38 @U9A1RLFNV Do you still want an issue opened?

It's not needed anymore

Awesome!

Check your User settings JSON. You might need to remove any “[clojure]” settings there regarding auto-closing brackets.

Ah, looks like I had ""editor.autoClosingBrackets": "never" in there. I definitely don't remember adding that , but thanks @U0ETXRFEW!

I’m guessing you briefly had Calva 2.0.227 installed. It manages these settings. And then when we reverted that I think many users get a bit wonky settings…

You could try set the clojure-lsp path to something gibberish. I think that should disable clojure-lsp. To see if that gets rid of the lock-ups. If it doesn’t, then it is probably something in Calva.

when it freezes, check clojure-lsp log via terminal with tail -f /path/to/clojure-lsp.log

you can set the :log-path as well in the clojure-lsp config