Clojurians Log v2

(I'm investigating because it currently https://github.com/clojure-lsp/clojure-lsp/issues/1935 and I'm trying to understand what's going on).

I'm not sure about how vscode triggers the linkedEdit, but for emacs you need to manually call a command to then start editing and other things change too

I doubt vscode has something automatically, you probably need to trigger something to activate the linkedEdit

Ah, no, it's definitely automatic in VSCode. Here's what editing an HTML tag looks like in VSCode without linked editing enabled:

And here with it enabled (this is a global checkbox, not a per-edit setting):

interesting, so maybe it's something calva needs to opt-in when starting clojure-lsp, one way to confirm is checking the initialize request sent from client, to check if linkedEdit capability is on

Thanks, I'll take a look. Zed has linked edits enabled by default, which means that editing a Clojure file becomes something of a crap shoot until you disable it 😞

Yeah, I personally would like a setting like that to be enabled by default like that html experience

That makes sense. But if that's the case then the current clojure-lsp implementation is much too eager (by default it renames every single instance of every symbol, which almost certainly isn't what you want).

yeah, I implemented that feature and never iterated over that, especially because no one complained, so LMK if there is something to be improved, feel free to create a issue in clojure-lsp

Already have 😉. But I want to understand why it's not working in VSCode before I try to work out what should happen.

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

makes sense

I can take a look soon

While I'm bothering you, have you noticed the PR I created yesterday (also to fix a Zed issue): https://github.com/clojure-lsp/clojure-lsp/pull/1934

ah not yet, I was on vacations until today, will take this week to check github notifications and prioritize, I'll take a look at that probably tomorrow or Tuesday

Thanks!

Well, this explains why linked edits don't work in Calva: https://github.com/BetterThanTomorrow/calva/blob/published/src/lsp/client/client.ts#L173

Looks like it was disabled because of a bug right after the functionality was implemented in clojure-lsp, and never revisited: https://github.com/BetterThanTomorrow/calva/pull/1389

oh, would be nice to re-enable and test if it's working c/c @brandon.ringe

I've added a discussion thread to clojure-lsp describing how I think things should work: https://github.com/clojure-lsp/clojure-lsp/discussions/1936

I re-enabled linkedEditingRange in Calva in a PR. I'd like some testing by people who've experienced the issue before merging. See this comment: https://github.com/BetterThanTomorrow/calva/issues/1374#issuecomment-2585923203

I'll look at it @brandon.ringe. When you say you can't reproduce the issue, do you mean: • You don't have Linked Editing enabled in VSCode? • You do have Linked Editing enabled in VSCode, but everything works fine for you? • Something else?

I've created a PR which goes some way to fixing the problems, although not all the way there yet. https://github.com/clojure-lsp/clojure-lsp/pull/1947

changes looks good, would be nice to change integration-tests as well

Oh, sorry - I forgot about those. I will take a look if you think that it's worth merging (but I think we need to address the timing-related issue before doing so?)

I'm ok merging this one before as current linkedEditing is pretty agressive, so I see that PR as a good improvement, the timing issue may be hard to fix

also, interested if the timing issue happens for all linkedEditings, like the let local bindings or only for the alias case

If the timing issue can't be fixed, the right solution is to ditch the functionality entirely. Otherwise it will just cause frustration (remember that linked edits are enabled by default in Zed)

And yes, I saw it across all kinds of linked edit.

yeah, I wanna see it and understand it better before we take an action like that, maybe it's something we can workaround

Fair enough. The blast radius will be much (much!) smaller with this PR.

Agreed

I've just run the integration tests on my Mac and they all pass?! I don't understand why?

I'm running them with: bb integration-test ../clojure-lsp in the cli folder. Am I missing something?

usually I just bb integrration-test on clojure-lsp root, but it should be the same

if they pass they are probably testing few stuff

this is https://github.com/clojure-lsp/clojure-lsp/blob/918d13805eee5a7177806746f4df2b002e7fe602/cli/integration-test/integration/linked_editing_range_test.clj#L1

Ah, let me try that

Is there a way to run just the linked_editing_range integration test (will make it easier to debug!

tip: edit the entrypoint.clj removing other tests and leave only the feature you are changing, so it's fast to run

BTW, the reason why I'm running them in an odd way is that the instructions [here](https://clojure-lsp.io/development/) don't work: they say bb integration-tests (note the extra "s") so I fumbled around and thought I found the right incantation.

Thanks

ah, will fix that

Oh I may have misunderstood the issue. I don’t know if I had linked editing enabled. I’m afk right now and will be on a week-long trip starting soon. If you take a look though, @paulbutcher , that would be great.

Just tried it out. Headlines are: • There still seems to be an error (not sure why it happens in VSCode and not Zed 🤷) • That being said, the behaviour is then exactly what I'm seeing in Zed (i.e. unhelpful)

Hmm. I'll not merge that PR then. If anyone who can reproduce the issue can also look into a fix, that would be ideal.