@U066L8B18 you can use latest Calva tonight. 😃 @U066U8JQJ the grammar for keywords is sane again.

Amazing. Thanks!!

(please tell if you'd prefer that in a Github Issue)

I'd love me a Github issue. That's a bug.

Oh, and big thanks for testing and reporting! The function rangeForCurrentForm in src/cursor-doc/token-cursor.ts has some specification on how it is supposed to work. https://github.com/BetterThanTomorrow/calva/blob/dev/src/cursor-doc/token-cursor.ts#L650

Great to have such documentation. Here: https://github.com/BetterThanTomorrow/calva/issues/1577 Thanks!

Thanks! FYI, you can also just use Paredit Expand Selection to see what Calva considers to be the current form.

Oh. That is great. 🙏

I made a little video about it https://m.youtube.com/watch?v=8ygw7LLLU1w&feature=youtu.be

I’m not a big fan of codelenses. Which might explain why this is not enabled by default. Maybe we can think of ways to make clojure-lsp features more discoverable in general?

I think it tends to make code jump around as the code is edited, because the lenses are recalculated, so they disappear and reappear during editing. I seem to recall it being annoying, so I disabled it.

Maybe there is some way to fix that, though.

I asked because most IDEs including other languages have that enabled as default

In my experience most users tend to like it, and the ones that doesn't could disable it

@U9A1RLFNV maybe there is a way to show lens on right side instead of up? Vim and emacs show this way, avoiding code jump around

I've only seen code lenses above. My personal preference is to have code in the code area or my code editor. Light bulbs and buttons confuses me. I don't think I'd fancy having the code lens there by default. I'd rather explore some way to surface clojure-lsp goodies you might be missing in some way. (No idea how, and it is not limited to clojure-lsp, I generally think surfacing important/nice features is tricky.)

I have it enabled, it's just that I already saw some people that never heard about it and liked the feature but had no idea that exists. Especially re-frame/cljs users, since we have the lens showing the references of subscribers/events which is pretty handy to even highlight to people that is possible to find-definiton/references of those handlers

I bet most calva users don't know about it since it's not obvious that you can call references/definition of a keyword defined by re-frame, unless there are code lens references showing that

Yeah, I had a co-worker who I think didn’t know that was possible with re-frame keywords until I showed him.

We could always just enable code lenses by default for a while and see if we get any complaints or many questions about how to disable it. If we do, then we can go back to disabled by default, else, we leave it.

Yes, lsp-mode had that disabled and after a while we realized that most users/other languages prefer that enabled

The setting to disable is pretty easy to find on calva settings as well

And maybe something on the documentation would help as well

@U0ETXRFEW If you agree to try it out I think we should make that change.

I don't really agree. 😃

Never mind then 😄 ¯\(ツ)/¯

I much rather see if we can make this page https://calva.io/clojure-lsp/ more about what clojure-lsp brings to the table. And use it to inform about how to enable things like this code lense.

That would be good. We could also probably implement some “Did you know?” type of information messages that can be set to not show again, about certain features, that show in certain situations. We could isolate these to a single module, as well. For example, a user opens a Clojure(Script) file and has references code lens disabled. A message pops up like “Did you know you can easily see the references for a function with references code lens [link to docs]? Enable it in settings.” Then the user can press “Don’t show again.” Setting up the right triggers and making sure we don’t show more than one at a time, or too close together in time, would be something to be mindful of, but there could be a declarative, programatic system that handles that.

We could, this does makes sense too, but won't make people that don't check the docs aware that feature exists. I like to think that makes sense give it a try and rollback if too many issues what I doubt

I already think vscode has too many popups that show up when I open it, I'd prefer to follow the idea of good defaults instead of asking questions

I agree about popups. We just have different opinions on good defaults here. Code jumping around is not nice, imo.

And I am not totally opposed to try find ways to introduce features via popups. It is just quite tricky to do in a way that doesn't disrupt. There is a whole ”getting started” API thing that we haven't explored though.

> Code jumping around is not nice I agree, but also I don’t think I’ve seen this jumping with references code lens in other languages, so maybe there is a way to fix that.

And that getting started API sounds worth exploring.

We should try to see if we can fix that jumpyness.

maybe Calva is requesting code lens all the time instead of caching, but I thought this was the default for vscode, on lsp-mode we implemented this caching logic

I’ve got the references enabled for a long time now and don’t remember any jumping. Maybe it was slow early on and it’s fast now?

Maybe so, I need to try it again… That would be great if it’s not an issue any more.

Wow I had no idea this was available.

Ok so I just enabled references code lens again and I don’t see the jumpiness I used to see. 🎉

I’m going to leave it enabled for now and see how it goes.

So it seems if forms become unbalanced, then the references code lenses disappear, and upon rebalance, they reappear (probably because clojure-lsp can’t analyze the file if it’s not balanced, though maybe Calva can do something about this). I just noticed this when setting paredit to original mode, but in strict mode maybe it usually won’t happen.

Yes, this is something to be handled on Calva probably, emacs doesn't remove lens when invalid code

Issue created: https://github.com/BetterThanTomorrow/calva/issues/1586

For example, one can test completing defmethod and trying to press Tab to move to the next element selection, but it doesn't move. I tested with Dart LSP and it seems to work, so maybe something with calva dependency or something?

Are you talking about the suggestions pane?

tab selects the currently highlighted suggestion, and the up and down arrow keys navigate the suggestions. This seems related to this question: https://clojurians.slack.com/archives/CBE668G4R/p1646462264982019?thread_ts=1646413001.692809&cid=CBE668G4R

There’s a solution in that thread ^

No, I meant, after selecting the snippet from completion, when the snippet text is insert, if you press tab, it should go to the next text that the snippet has configured

Example: https://images.app.goo.gl/zC9L4GvAbC7uCG6z6

Check how one moves to the next place, it's what tab does in snippets

This is called tabstop

We're using tab for formatting and are missing to check for inSnippetMode context. You are welcome to file an issue about it, @UKFSJSM38.

Linking here: https://github.com/BetterThanTomorrow/calva/issues/1580

Might be fixed now. in v2.0.252. I fixed it blindly as part of another update I needed to do, so that's why ”might”.

Thanks!