Fork me on GitHub
#lsp
<
2023-05-16
>
viesti05:05:22

A thought occurred to me: When typing a literal namespaced map, is clojure-lsp able to use the namespace of the namespaced map to sort the keyword completions (so as to offer keywords, that have the same namespace as the literal namespaced map, first in the list of completions)?

ericdallo11:05:34

It's possible, clojure-lsp doesn't do that for completions at the moment, but it has the analysis to do so

ericdallo11:05:53

Could you open an issue with more detailed examples and expected output please?

viesti11:05:27

Thank you for answering, and thanks for pointing out to write an issue, writing helps to clear my thoughts too 🙂 I'll see if I can write an issue, the idea that lead me to this asking this is a bit specific and maybe out of scope (writing Terraform config as EDN while providing autocompletion), but started to think if there is something here that could be generally helpful.

ericdallo11:05:21

Yeah, I can see how convenient it is to suggest first the keywords of the namespaces map in the namespaced map, but seeing a real example would be good

ericdallo13:05:00

AFAICS looks like a nvim LSP client issue, I don't know those details, maybe ask in #C0DF8R51A or wait for other people that can help

Ory Band08:05:56

this doesn't happen in other LSP servers (eg Python). It happens when trying to open zipfiles / jars from $HOME/.m2 directory, which is were library deps are located

Ory Band08:05:45

i'm on nvim 0.9.0 . downgrading to 0.8.3 returns same error but nvim doesn't hang afterwards

Ory Band09:05:28

trying to open the file directly with zipfile scheme opens an empty buffer and nvim hangs:

# nvim zipfile:///home/ory/.m2/repository/com/stuartsierra/component/1.0.0/component-1.0.0.jar::com/stuartsierra/component.cljc
and the swap file created (because nvim crashed) shows this one, why all backslahes turn into % ?
# ls
zipfile:%%%home%ory%.m2%repository%com%stuartsierra%component%1.0.0%component-1.0.0.jar::com%stuartsierra%component.cljc.swo
 zipfile:%%%home%ory%.m2%repository%com%stuartsierra%component%1.0.0%component-1.0.0.jar::com%stuartsierra%component.cljc.swp

Ory Band09:05:18

calling nvim --noplugin --clean zipfile:///... opens the file correctly

Ory Band09:05:39

found the plugin and neovim version combination that cause the issue. Probably irrelevant to clojure-lsp . https://github.com/Olical/conjure/issues/494

Ory Band11:05:14

Also, reason I got the first error (cursor position outside buffer) was because I was using Lazy plugin manager which disables Neovim's zipPlugin by default - so opening zipfiles fails. Re-enabling this pluging moved me to the next error, where CPU util is 100% by clojure-lsp process

ericdallo16:05:16

Sorry for the delay, glad you found the plugin cause that, I recall seeing other people with same issue

Ory Band17:05:52

no, its clojure lsp, not conjure

Ory Band17:05:15

disabling conjure still reproduces the issue and you can see clojure lsp is on 100 cpu util

ericdallo17:05:23

Hum, when clojure-lsp opens a external .class file it decompiles it, besides that there's nothing that should use a lot of CPU, only the didOpen request which calls kondo to analyze the file, but should be fast.

Ory Band18:05:40

it's a clojure jar file, not a java class.

Ory Band18:05:01

is there any way I could debug this and provide more information for investigation?

ericdallo18:05:02

Sure, a good first step is check client<->server logs and then check how much time each one is taking when going to the jar