Calva randomly edits file while in Live Share

[simonvea]

Issue Type: Bug

When in Live Share the current file is edited randomly, adding brackets and new functions.

No keys are pressed.

It does not happen if we disable the Calva extension.
It also does not happen if we do it in read-only mode.
Both/all have the Calva extension.

Se videos in the Calva slack channel for an illustration. Here and here.

We have debugged some and changed versions of both Live Share and Calva.
It works in Calva version 2.0.225, but not those after.

Extension version: 2.0.229
VS Code version: Code 1.63.0 (Universal) (7db1a2b88f7557e0a43fec75b6ba7e50b3e9f77e, 2021-12-07T05:15:48.091Z)
OS version: Darwin arm64 21.1.0
Restricted Mode: No

System Info

Item	Value
CPUs	Apple M1 (8 x 24)
GPU Status	2d_canvas: enabled gpu_compositing: enabled metal: disabled_off multiple_raster_threads: enabled_on oop_rasterization: enabled opengl: enabled_on rasterization: enabled skia_renderer: disabled_off_ok video_decode: enabled webgl: enabled webgl2: enabled
Load (avg)	5, 4, 4
Memory (System)	16.00GB (0.47GB free)
Process Argv	--crash-reporter-id d27e1569-32d1-4cea-a762-53ae3d4f0980
Screen Reader	no
VM	0%

A/B Experiments

vsliv368cf:30146710
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vstes627cf:30244335
pythontb:30283811
pythonvspyt551cf:30345471
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
pythondataviewer:30285071
vscod805cf:30301675
pythonvspyt200:30340761
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
pythonrunftest32:30373476
pythonf5test824:30373475
javagetstartedt:30391933
pythonvspyt187:30373474
vsaa593:30376534
pythonvs932:30410667
vscop804cf:30404767
vscop453:30404998
vsrem710:30405998
vscexrecpromp3t1:30407762

[PEZ]

Over at slack was noted that this works in v2.0.225. and stops working in v2.0.0226. I'm staring at the 226 changelog and can't for the life of me figure out what caused this:

• Internal: Handle the unknown-op status from test commands
• Fix: textDocument/linkedEditingRange failed when opening files or moving cursor
• Fix: paredit.spliceSexp doesn't work with set literals
• Fix: LSP code actions not working

Do you have any ideas, @bpringe , @ericdallo ? Pinging in @marcomorain for good measure, and we should have all people involved in the relase pinged, I think.

[ericdallo]

Yeah, looks like calva is applying code actions automatically, @bpringe sounds like your fix on calva is not working with latest clojure-lsp, maybe it's applying the code action automatically when it has edits?

[marcomorain]

I don’t think my changes are related in this case. I never make any changes to documents.

[PEZ]

Seems you already understand the issue, @ericdallo , but anyway, here's a vid posted on Slack where the user is not typing anything, only moving the cursor.

Bildschirmaufnahme.2021-12-13.um.15.54.02.mov

[ericdallo]

yeah, code-actions are calculated each time user changes cursor, so it explains the weird behavior if calva is indeed applying the code actions every time a new one is available

[bpringe]

I don't see how the change in #1400 would be causing this issue. Calva is only running code actions if a resolve request is sent, and the response contains a command to run. Moving the cursor around a file only causes textDocument/codeAction requests to be sent, the responses for which don't contain edits or commands.

However, since the changes in the image do appear to be code action changes, and since this started happening in 2.0.226, that PRs changes must be related.

Since codeActions are a convenience feature and a workaround exists for running them (at least for some of them, you can run the associated Calva Refactor command), and since with clojure-lsp updates we should soon be able to have the code actions work without those changes, I'm going to revert them.