This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (1)
- # announcements (1)
- # babashka (6)
- # beginners (25)
- # biff (6)
- # calva (61)
- # clojure (15)
- # clojure-europe (2)
- # clojurescript (34)
- # cursive (7)
- # events (2)
- # figwheel-main (5)
- # fulcro (10)
- # gratitude (1)
- # malli (2)
- # pathom (1)
- # polylith (3)
- # portal (1)
- # re-frame (3)
- # reagent (10)
- # releases (2)
- # shadow-cljs (19)
- # spacemacs (5)
- # xtdb (2)
Dear Calva friends: Now the fix is out. Calva v2.0.250. Would not have been able to fix it this quickly without the help from @corasaurus-hex https://github.com/BetterThanTomorrow/calva/releases/tag/v2.0.250 • Fix: https://github.com/BetterThanTomorrow/calva/pull/1573 • Fix: https://github.com/BetterThanTomorrow/calva/pull/1576
@U066L8B18 you can use latest Calva tonight. 😃 @U066U8JQJ the grammar for keywords is sane again.
Confusing behaviour with the current version:
If I put the cursor between the two forms,
(+ 1 2) ^:abcd/efgh [:hello]
Calva: Evaluate Current Formwould evaluate the second form. If I remove the metadata, it would evaluate the first form. Many thanks again. 💜
(please tell if you'd prefer that in a Github Issue)
Oh, and big thanks for testing and reporting! The function
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
Any reason to not enable reference code lens on Calva by default? IMO is one of the best features of clojure-lsp that is not available on ther editors/tools and I suspect a lot of calva users doesn't even know that exists, WDYT?
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.
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
@U0ETXRFEW If you agree to try it out I think we should make that change.
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.
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?
Ok so I just enabled references code lens again and I don’t see the jumpiness I used to see. 🎉
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
One other question: Does completion snippets work properly on Calva? I tested and it seems when I press
Tab it doesn't move to the next tab selection 🧵
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?
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
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
tab for formatting and are missing to check for
inSnippetMode context. You are welcome to file an issue about it, @UKFSJSM38.
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”.
Calva v2.0.251 just out: • Fix: https://github.com/BetterThanTomorrow/calva/pull/1577 • Fix: https://github.com/BetterThanTomorrow/calva/pull/1578