Use clojure-lsp for drag

[mainej]

I'd like to propose that Calva use clojure-lsp's drag-forward and drag-backward commands as replacements for its current implementation. The clojure-lsp's version offers a few improvements over Calva's:

• comment affinity: as a clause is dragged, affiliated comments—those preceding it or at the end of its last line—are dragged too. This keeps comments associated with the correct chunks of code.
• clause awareness: clojure-lsp uses context to decide how many elements to group together in a clause. Calva does this too, but I think clojure-lsp handles a few more cases:
  • Individual elements by default.
  • Pairs of elements in maps.
  • Pairs of elements in several known binding forms: binding, doseq, for, let, loop, with-local-vars, with-open, with-redefs.
  • Pairs of local variables and their values, as defined by clj-kondo analysis. This allows library- and user-defined code to participate in pair-wise movement by declaring that it establishes bindings via, for example, :lint-as {my.ns/my-let clojure.core/let}. This is also the current mechanism of supporting pairwise movement within :let forms in for expressions.
  • Pairs of elements in cond, cond->, cond->>, assoc, assoc! and case. These are all careful to avoid dragging ineligible elements—for example in (cond-> {} a (assoc :a 1) b (assoc :b 2)), the cond-> and {} are not eligible. The optional final default expression in case is not eligible. All of these—aside from cond—occasionally appear in threading expressions. When they do, the eligible elements are adjusted.
  • Pairs of elements in condp, or triples of elements in its ternary form. The first three elements are ineligible, as is the final default expression when present.
  • An adjustable number of elements in clojure.test/are, based on the number of args in the template.

I'm the author of the clojure-lsp implementation, so whether or not it's a good fit for Calva, I'd love bug reports or feedback on ways it could be better. If the descriptions above aren't clear, there are pretty extensive tests starting here. If using clojure-lsp's version isn't feasible for some reason, feel free to borrow these features. Calva was the first editor that I'm aware of that did Clojure-aware dragging, and so I think it's only fair that clojure-lsp shares.

Cheers!

[mainej]

Note that clojure-lsp has equivalents only for drag-{forward,backward}, not drag-{forward,backward}-{up,down}.

Personally (I'm an Emacs user primarily) on the rare occasions that I need something like drag-forward-up I know I can simulate it with a combination of drag-forward and barf-forward. Other similar situations might need slurp-{forward,backward} or barf-{forward,backward}.

Or to put it another way, as I see it, drag-forward-up and barf-forward are equivalent commands, differing only in the location of the cursor before and after the command is executed.

In any case, I don't expect to add the {up,down} variants to clojure-lsp.

[PEZ]

Thanks for noting this. I don't think it is much of a problem. If we find a way to let users use clojure-lsp for fwd/back then people can still user Calva's implementations for dragging things in/our of forms.

[PEZ]

Thanks for this suggestion! It is on my TODO since a while to have a look at how we could improve drag fwd/back, inspired by clojure-lsp's amazing treatment of the feature. Super well done!

Also thanks for the overview and details offered. This would have taken me much time to figure out on my own.

If we can expose clojure-lsp's drag operations as commands, then users can configure their keyboard shortcuts to prefer it over Calva's implementations. I think that is the best way to approach this with a minimal effort spent, since Calva will need to support this even when clojure-lsp is not running.

Side-note: With more effort spent on this I would want to make clj-kondo analysis available to Calva. With that we could could enhance a lot of the structural awereness in Calva, and one place we could benefit from it would be to spiff up dragging.

Please file an issue about this, @mainej. I suggest framing it as something like ”Enable users to bind keyboard shortcuts to clojure-lsp drag sexp commands”. And, of course, please consider contributing the implementation in Calva. 🙏

[mainej]

OK, thanks @PEZ, will do. drag-forward and drag-backward are already commands on the clojure-lsp side. So for the Calva implementation, it looks like commands need to be defined in main.ts. Do they also need to exist in the "commands" section of package.json? What about the "keybindings" section of package.json? Anywhere else?

[mainej]

Agreed, having access to the clj-kondo analysis is very powerful. Exposing it to the editors sounds cool ... and hard. Perhaps this is a use case for LSIF. I've had vague visions of building an LSIF server that runs off clj-kondo analysis. Maybe clojure-lsp and the editors could all hook into a shared LSIF server. Someday...

[bpringe]

Interesting. I just read some about LSIF and I'm still a bit confused about what it provides in relation to clojure-lsp and how clojure-lsp would use it.

Can you explain a bit about how LSIF could improve the current situation of how clojure-lsp (for example) is used with editors?

The goal of the Language Server Index Format is to augment the LSP protocol to support rich code navigation features without these requirements. The LSIF defines a standard format for language servers or other programming tools to emit their knowledge about a code workspace. This persisted information can later be used to answer LSP requests for the same workspace without running a language server.

So clojure-lsp wouldn't need to be used (or at least no server needs to be running) to get some info that LSIF can provide? How would that work? Calva could just request this info using the LSIF protocol, from... what?

[mainej]

Sorry... this is a totally half-baked idea. Really all I thought was "oh look, analysis data arranged as a graph; that's a nice idea; it'd be cool if clj-kondo data was arranged in a graph instead of a flat list; that'd make it much faster to navigate relationships." My thinking didn't go much beyond there.

To be honest, I don't understand why LSIF is speced as a static chunk of data. Much more useful, IMO, would be a live analysis server that updates as new analysis happens, and can be queried for the current state of the world. Clearly the Microsoft folks have a different vision for it than I do.