we could do on server side, but not sure it's a good idea, this is mostly a clent UX issue, you could disable on calva or delay it

because calva has hover automatically enabled when hovering, for emacs/vim for example this is not true, only when user requests it we show

What is the use case to show documentation on a keyword? Is it metadata etc?

Yeah, I had hovers disabled because it's obtrusive but there's no fine-grained knobs in VSCode, it's all or nothing.

Perhaps Calva needs those knobs, but I wasn't sure if keywords was just noise or if there was something more to it.

I still think calva needs it, because even if we disable hover for keywords user can still face those issues in functions and almost anything

Yeah, I think disabling some classes of hovers might make sense (e.g. I don't like clojuredocs popping up all the time)... But I was wondering about keywords, like what's the point of showing info on :div? Genuine question 🙂

I can't see a reason easily, probably it could be droped

There might be a thing with fully-namespaced keywords e.g. for re-frame - but I don't use re-frame so not sure what are the various practices there.

Also keywords in theory could have "hierarchies"

yes, but for simple keywords, not namespaced, probably no one wants to hover?

even so not sure that would avoid vscode hover

I will look into turning this off in Calva and report back 🙂

probably it would show a empty hover window

Yeah that's what I fear 😄

what happens when you hover over ns symbol of a (ns foo) ?

because it would behave the same, we don't have analysis/hover for ns symbol

when you hover over ns nothing happens, when you hover over foo you see foo

all of those statements go out the window when you connect to a repl though since we then don’t ask LSP anymore and ns returns the ns specialform doc and :div doesn’t return anything…

so probably vscode is smart and when there is no hover it doesn't show a empty window

So I'm ok dropping simple-keywords from clojure-lsp, although it doesn't fix calva showing hovers all the time issue

:thumbsup: Yeah, doing that for simple keywords should be fine. We shouldn’t change LSP too much to fix IDE behavior.

Which isn't so much of an issue, I think. We might need to help people find good settings. But there is not all that much we can do about VS Code UI/Ux. Calva has as few knobs as we can get away with. Each knob adds maintenance and user cognitive load.

true, a lot of the calva annoyances are actually vscode problems or default settings that users should change

I’ll have to ask @U02G2ADG5S6 for a sabbatical to learn that one 😭

Plus I don’t think emacs is known for “just use the defaults, no settings needed” …

indeed :man-shrugging:

at least has options, but it was just a joke

😃

There are always trade-offs. ¯\(ツ)/¯

yes, so feel free to open an issue about disabling hover for simple keywords, I think this is the best we can do from clojure-lsp side

I actually see clojure docs when hovering over ns 🙂

In vscode you can also trigger the hover from a key, So you can disable editor.hover.enabled and then create a key binding to editor.action.showHover. Might help to deal with the noise from auto hover.

I don't recall, but we already had tons of issues about that, probably it's right 😂 but, it also depends on the dependecy-scheme setting, it can be jar or zip

I have mine set to jar

I've noticed something, that I'm trying to gather some facts on

the jar scheme i believe is set to take advantage of vim's zip reader. basically copied from fireplace originally but it may have changed since.

What I've noticed is that if I goto definition, first time, it opens up the jar file, then if I go to it again, there is a blank response coming from clojure-lsp (therefore the contents are blank)

so, trying to figure out why that is

@U11EL3P9U we had a similar issue couple of releases ago on Calva, could you confirm you are using a updated clojure-lsp?

yup, using the latest. To be fair, I only just noticed it happening. I would have noticed it earlier (as I jump to jars quite a bit)

so, my gut feeling is that something has changed somewhere and it's sufficiently annoying me now to pay some attention to it and try to figure out what has happend 🙂

clojure-lsp 2022.02.23-12.12.12
clj-kondo 2022.02.09

fyi

yeah, odd, could you check client <-> server json logs?

Yeah we had that exact same issue. Last time it was based on lsp forgetting the file if it got closed in the editor or something like that? I remember you fixed it in lsp

ah found the context: https://github.com/BetterThanTomorrow/calva/issues/1494

Going to spend a bit of time today to see what is going on.

Getting somewhere...definitelysomething bizarre happening with the analysis.

For those interested. I solved the issue by using the dependency scheme of zip, not jar.

I suspect the jar problem might be that once you nav outside the project into the temp file, the client decides you're in a different project and gets confused for the next jump.

by solved, do you mean you changed it in the Calva source @U11EL3P9U? Or is it your own LSP client?

He uses nvim @U02EMBDU2JU

Do you know if nvim is built on top of some client lib or does it do its own LSP thing?

it has its own lsp client built-in on nvim

which I don't use

I don't use the built in lsp of nvim

I use CoC

the ability to navigate into the zipfile scheme tho is pretty vim specific.

Indeed, on emacs, the scheme is set to jar apparently.

yes, for Calva/Vscode too