By the way not sure how I feel about the fact that lsp-mode contains clojure-specific code

Is there a way to expose this functionality without coupling the client code to the target language?

A lot of functionality is available via eglot-code-action, but (please correct me if I'm wrong) not all

All those are custom requests and response that are not part of the LSP spec, multiple servers do that when they want a custom feature and the spec is not enough to support it yet

It needs custom code on client, and that's one of the reasons I find eglot a little bit outdated compared with lsp-mode

Another example is lsp-dart which has a lot of complex handling to custom dart server messages, I really can't see one using same features with eglot unfortunately

What if there was an add-on to eglot? Could this be implemented in another package?

Yep, probably eglot has functions to be extended just like lsp-mode

Gotcha, I'll take a look

It should be a good oportunity to eglot provide functions or recommended ways to extend if not exists yet

I wouldn't say Eglot is outdated compared to lsp-mode, it's scope is just different. Eglot aims to implement the LSP spec and nothing more. lsp-mode aims to support everything it possibly can related to lsp out of the box. I highly doubt Eglot will ever support these extension methods out of the box, they are too much of a moving target for something built into Emacs and somewhat tied to its release cycle. I think the maintainer of Eglot would say it is up to package maintainers and major-mode maintainers to implement specific extensions for relevant language servers. With that said, Eglot implements most of it's handling functions with generic methods that can be extended in separate packages. I think there is a need for eglot-clojure package at some point, especially now that Eglot is shipping with Emacs 29.

And it adds in square brackets, but parens is preferred for java imports in clojure style guide, as far as I know

and what does x 3,`x 0` means?

Log :

[clojure-lsp.handlers:246] - :document-symbol 0ms
[clojure-lsp.handlers:253] - :document-highlight 1ms
[clojure-lsp.handlers:253] - :document-highlight 0ms
[clojure-lsp.handlers:410] - :code-actions 105ms
[clojure-lsp.handlers:361] - :execute-command 66ms
[clojure-lsp.feature.file-management:241] - changes analyzed by clj-depend took 0ms
[clojure-lsp.dep-graph:269] - :maintain-dep-graph 0ms
[clojure-lsp.kondo:305] - Non-fatal error from clj-kondo: No configs copied.

[clojure-lsp.feature.file-management:237] - changes analyzed by clj-kondo took 29ms
[clojure-lsp.dep-graph:269] - :maintain-dep-graph 0ms
[clojure-lsp.server:552] - :analyze-file 29ms
[clojure-lsp.feature.file-management:139] - :reference-files/find 6ms
[clojure-lsp.feature.file-management:137] - :notify-references 6ms
[clojure-lsp.handlers:253] - :document-highlight 0ms
[clojure-lsp.handlers:246] - :document-symbol 0ms
[clojure-lsp.handlers:435] - :semantic-tokens-full 2ms - waited 143ms
[clojure-lsp.server:102] - :publish-diagnostics 0ms
[clojure-lsp.handlers:167] - :did-save 0ms
[clojure-lsp.handlers:422] - :code-lens 0ms

It works perfectly when there is only one class candidate

It means the number of usages across the project

Could you create a repro so I can try?

sure, give me few mins

https://github.com/armed/clojure-lsp-import-bug

kept same deps.edn

Thanks, I can try this soon today

> but parens is preferred for java imports in clojure style guide, as far as I know Which style guide, can you double check?

@U04V15CAJ you are right, I don’t remember where I saw that or I just misunderstood. Nothing found about parens in java imports. Sorry about that.

It's a clojure-lsp bug @U34K4458X, will create a issue and fix it for next release

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

thank you 🙏

Fixed, soon available at #C032YH7P0R2, thanks for the report

@U04V15CAJ regarding the import style: https://stuartsierra.com/2016/clojure-how-to-ns.html

mostly everything should work ok, for find defintion install jarchive, @UDVJE9RE3 has more context