They might play well together (as in: not clash) but CIDER is so complete it's unlikely that c-lsp adds extra value c-lsp might be recommendable if you are big on LSP and pursue a simple / uniform setup and are willing to drop CIDER for that

c-lsp adds a lot of functionality. i really like it

c-lsp supports things that don't require a repl which is noce

nice*

@U11BV7MTK which would be some nice examples?

rename, find-references, go to location are all quite nice

emacs has go to location but it requires active nrepl and file loaded

there are other refactorings i haven't gotten setup yet in emacs but are nice in neovim

I use clj-refactor (presumably a very usual choice between CIDER users) and I'm quite happy with it (plus I assume it will have superior accuracy) Personally the "no repl" argument is quite irrelevant to me, I don't work without a repl. It can lead to committing stuff one didn't even bother trying out. Plus spawning a repl is easy enough

Well, you always have to be running some server (a REPL server or an LSP server). Obviously, I’m fond of the REPL approach, but some people might prefer the other one.

If you’re using some very basic REPL (e.g. inf-clojure or another editor) probably c-lsp’s value proposition becomes way more appealing.

I am going to write my dream here 🙂 A server is a server so it could answer to the nRepl protocol on a port and to LSP commands on another port

😄 one also could think of a LSP server that "best-guesses" as its baseline smartness, but later if you fire up a repl, it will get CIDER-like smartness

Not all server are made equal though

An lsp server auto-sync with buffers, and its state can not be altered through a repl or in ad-hoc ways that don't match the source buffers.

And the best appeal to me, is that parsing for them is generally focused on being loose and heuristicall

Wheres as if you leverage the Clojure compiler and runtime for parsing, it will be very strict, as it should. But that's a different goal to what you'd want your editor to do.

Nothing specific to lsp. I mean, nRepl functionality could be designed with that in mind as well. But I'd argue at the very least, there should be one nRepl reserved to the editor, which is kept in perfect sync with the buffers automatically, and is relaxed in its parsing and used for auto-complete, refactors, go-tos, etc.

And another one for repl usage. Where the user is free to manually control what gets loaded, and can run code directly in it. Etc.

Not complaining, I love cider, nrepl and clj-refactor, but lsp has a simplicity to it which is appealing, and more of a it just works all the time. Where as normal nRepl requires more out of me, to make sure I'm in sync, I reloaded things properly, that I don't have any unbalanced parens, or syntax errors, etc.

You are right state management is completely different, probably none is probably shared between the two. We might discover some neat thing by going through the exercise, very interesting..

I don’t get how state management can be a server’s responsibility. Typically clients should decide what they want to sync. I think you actually meant to say that LSP actually operates on the raw source code of the project, otherwise it can’t really have meaningful AST for the entire project. That’s certainly a reasonable approach for finding usages/definitions/etc. There’s nothing preventing nREPL clients from auto-loading all project files on every change to those files, btw, but it’s generally a bad idea to evaluate unconditionally code that might have some side effects.

another nice aspect of the static analysis is that it is instantly up for new projects. No messing with figuring out which profiles are needed, how to get nrepl up, possible clojurescript choices, it just starts analyzing symbols. Its quite nice.

Well, you still need to setup the LSP server and clients, though.

I think the only free lunch is something like ctags. 😉

Anyways, I haven’t used LSP much, so perhaps this works better than I think it does.

Lsp-mode currently starts the lsp server automatically mostly. But ya, there's still some setup required for the classpath.

Using the repl for a lot of these features make sense, since static analysis is hard. That said, I think static analysis could be a nicer UX once it works. You'd still want a repl for all eval related tasks.

The lsp server is just a good way to allow to not have to re-built that analyses in every editor

That said, as an Emacs user, I'd also be happy with Emacs natively being able to analyze and perform these features just with Clojure mode 😋

Ctags/ggtags is awesome I tried to use it but the built in parser is not that sophisticated