Fork me on GitHub
#lsp
<
2022-04-13
>
rayat02:04:20

> As we do work within Calva to combine LSP/REPL-provided info for IDE ergonomics, I'd hate to miss out on contributing such work language-agnostically to other clojure-lsp-using tools. 1. Is there any way to somehow forward or share the REPL connection to clojure-lsp so that it becomes the "source of truth" for whatever language features IDEs gain when jacked-in? The REPL is still connected to the IDE for inline evaluation, debugging etc, but language features exclusively come from clojure-lsp (or at least that's the idea). 2. This (perhaps hand-wavingly) simplifies lsp-client/IDE language-feature logic for clojure-lsp consumers a. eg they no longer have to implement Go To Definition themselves b. eg they no longer have to implement the merging of LSP and REPL provided completions themselves c. etc 3. And this allows contributions and optimizations to c-lsp to only have to be done once, sharing the spoils with all Of course those benefits are only possible if it's technically feasible and otherwise desirable to have the LSP also embed NREPL or something, or whatever it is that it would actually take 🤷:skin-tone-4:

ericdallo11:04:59

Not sure if I got it, but your idea is to make clojure-lsp use the REPL somehow? That's probably something we don't like it to introduce to clojure-lsp for now, LSP use static analysis and it's already a huge project, merge it with REPL capabilities would make things harder in multiple ways. There are already multiple tools that offer repl features, about 1. you are probably interested on this calva issue https://github.com/BetterThanTomorrow/calva/issues/1498 where it'll be possible to tell calva from which source it will use that feature

1
lread15:04:29

I am really loving the clean-ns support! It is marvelous! I am wondering (if the ability is not already present and I’ve just missed it) if it would make sense for clean ns to also sort imported class names. For example:

(ns some.ns.here
  (:import
   (a.lovely.java.package Fabulously Sorted Absolutely)))
Would be cleaned to:
(ns some.ns.here
  (:import
   (a.lovely.java.package Absolutely Fabulously Sorted)))
Happy to raise a git issue if this is a good idea.

ericdallo15:04:22

Thanks! This should already happen, if not there is a bug :)

ericdallo15:04:32

Feel free to raise a issue!

ericdallo15:04:59

I think we sort only the packages not the inner classes

lread15:04:24

Yeah, that is the behaviour I am seeing.

lread15:04:34

Happy to raise an issue!

👍 1
lread15:04:12

So probably a feature request rather than a bug?… I’ll raise it as that.

lread16:04:06

I could take a crack at PR, but it won’t likely be soon soon.

ericdallo16:04:02

Np, I should take a look after some high priority issues

❤️ 1
snoe17:04:38

I think refactorings can make really good first issues too; tdd works well for these, and learn about zippers too. I know there's the label in github @UKFSJSM38 but it might be nice to document this as an example to follow to encourage more refactoring prs.

ericdallo18:04:18

Sure! I add those when I notice it's a good first issue indeed, I started with issues like that 😅 Will add that label for this one