Clojurians Log v2

I was thinking this as well ^. Some dev/contrib/how-to-hack guide.

Good tip, I can help with that docs

@pez To send from Calva's code, I think you can do something like

const serverInfo = client.sendRequest('workspace/executeCommand', {
                    'command': 'server-info'
                   });

INFO  clojure-lsp.main: Starting server...
INFO  clojure-lsp.main: ====== LSP nrepl server started on port 35353

Calva implements server-info already. That is not the issue here. What I was doing was to extend server-info and I wanted to test that from Calva. The only way I could figure out to do it was to build a new jar, install that in Calva and restart the extension host. A roundtrip of several minutes. I want to keep Calva’s extension host running, connected to the lsp server while I am modifying the lsp server.

Yeah, a docs describing a basic dev flow and how to get the nrepl port would help with that indeed

Didn't realize Calva implements it now, lol. I see what you mean though, it would be ideal to be able to modify the lsp code that Calva is talking to, from a repl.

I have been reluctantly doing that roundtrip for some time to test certain changes

yeah, I almost don't use that, since in general a test cover what I'm working for, but for calva test I agree this is a good aproach

@pez I just did it 🎉

1. Open clojure-lsp in vs code (you want to have this open first so it's clear that the last nrepl port you see in the logs later is the one for your extension host client) 2. Start the extension development host for Calva in another vs code instance and open a project, then wait for clojure-lsp to start 3. Look at /tmp/clojure-lsp.out for the last place it said the server was starting, and note the nrepl port. e.g. ====== LSP nrepl server started on port 36387 4. Go back to the clojure-lsp project, and run the Calva connect command, using the port from the logs 5. Open clojure-lsp.handlers ns, change something in the server-info function (add a map entry), then in your extension host run the server-info Calva command and you should see the new data you added to server-info

I was able to see the changes I made in the repl, without restarting my extension host (ran the command, then made the change, ran it again, saw the change)

I guess this info should be in the dev guide

Ah, see nvim starts up clojure-lsp for the clojure-lsp project, so I can call server-info and then connect to that port and start evaling

I guess the trick is for dev to have your client launch lein run instead of a binary.

https://github.com/snoe/dotfiles/blob/fc72fa3120890d5d1caaa74da7699a04b2a337b6/home/.vim/coc-settings.json#L10

First review for 1108: https://github.com/borkdude/clj-kondo/pull/1108. @snoe

for 1109 (https://github.com/borkdude/clj-kondo/issues/1109) I have trouble understanding why exactly you need the location of the var name symbol. Does this have to do with 1108 / local analysis?

I have read all the linked comments, but I still don't entirely grasp it, so some elaboration would be welcome

@borkdude hrm ok I'll give it a shot, if not maybe we can hop on a voice chat. It's not related to locals but locals might also need this info, right now I think we don't but vars are less consistent about pointing at the name. So the main API for LSP clients generally send a filename and a position to the server (clojure-lsp). So for example (simplified) we see (rename file.clj 10 1 foo). Then our job is to find the thing under position 10,1 so we know what we're renaming. I can't see how to find what's at that position from kondo's analysis as is (ignoring locals). So I imagine our code would look through var-definitions and var-usages for the file, and find the thing that encompasses the 10,1 position in that file. From there we find the definition and other usages and perform the rename. What I saw when I tried that earlier is: (defn b|ar []) would come up blank, because the bar definition is at col 0 and defn usage is at col 1, and I can't find what's up fee the cursor. I'm happy to figure out what's under my cursor some other way if I'm missing something.

Ah I see. So, from the clojure-lsp lib, how easy / difficult is it to look one token to the left and infer that the name is a var name, hence you should look it up by the location of the form wrapping it?

so like tokenize the file, and jump left to see defn then assume I was on the name? that gets nasty with metadata and stuff and defn-like macros.

yeah ok. I was thinking the analysis data can get crowded with info that not everyone might need, so maybe hiding this behind an option (like suggested in the other issue) might be nice

knowing where the form is also a parsing task I think.

Yeah, I when I was doing the locals flag, it felt maybe too specific, maybe there's simple and full analysis, but lots of different options as you described in the other issue makes sense too.

{:output {:analysis {:var-definitions {:name-locations true}}}}

maybe, I guess whatever feels most idiomatic to kondo

I think that will work, reflecting the structure of what is returned, a bit

so every sub thing can have new options for additional info

and this can be documented here: https://github.com/borkdude/clj-kondo/blob/master/analysis/README.md