Fork me on GitHub

Hi #calva, noob question: how do I see the Clojure documentation within Calva? In Cursive and Chlorine, I was able to refer to the Clojure documentation (or Clojuredocs) within the editor line. This made it really nifty to check if I got the right function or commands using a keyboard shortcut. But i can’t seem to find this within the Calva docs, so it would be great if someone could point me to it please. 🙂 Thanks!


If you just cmd/ctrl click, it doesn't take you to the clojure docs? For me it does. You can also setup keybindings to have a shortcut to go to the definition

👍 1

If it is examples you are looking for, Calva does not yet provide those. There's this PR where we track this lack.

👍 1

noted, thanks very much @U0ETXRFEW!

Fahd El Mazouni07:10:57

Hi there ! I get a weird bug from time to time where my repl output window doesn't update at all (I've tried refreshing it but doesn't do much) any tips on how I can find the root cause once I get the bug again ?


Sounds like something hangs. Have you tried closing the output window and opening it again?


That’s for trying to unhang things, for finding the root cause… Do you get inline display of results in the files still, or does that stop working as well?


The VS Code dev console might have some clue. (I doubt it a bit, but its worth checking.)

Fahd El Mazouni09:10:53

I'll try to check next time. Evaluation works fine but no result is printed (inline nor window) closing the output window and opening it doesn't help either, I generally fix it by running a lein clean on my project and reload vscode (a few times doesn't always work startight away)


Sounds awful. Let’s hope we can track this down!


is is possible you have evaluated something and its taking ages in the background? e.g., if you evaluate an infinite loop, then you won't be able to evaluate anything else. WHen it happens again, you could try right click and try Interrupt Running Evaluation and see if after interupting you can eval stuff again ?? Just a thought

👍 1
Fahd El Mazouni08:10:21

thanks for the tip Stuart ! I really don't think so, but I'll check this too

Fahd El Mazouni13:10:55

reproduced the bug just now

Fahd El Mazouni13:10:25

looked at the console and can't see anything related to this

Fahd El Mazouni13:10:16

no long running evals either


Any idea why Calva's lint tells me aleph.http/post (defined in the library by a macro) is an "unresolved var" while running clj-kondo standalone (with the same config) does not? It complains about occurrences both in app source (`/src`) and in test source (`/test`). If I open the app source while where it complains, it stops complaining about that. However opening the test files (or even running the tests with kaocha from the repl) doesn't have the same effect. Any idea what's going on?


Not really. There are a few layers to this. I think @UKFSJSM38 , or someone else #lsp savvy probably has a better idea.

😢 1

@UAEH11THP are you using latest clojure-lsp, we fixed a issue related to this recently, also try removing .lsp/.cache and restarting vscode


how recently is this? i started from a fresh install on friday. where can i check lsp's version?


It prints on calva says output I think


The most recent is the version from 30/September


Anyway, try the cache removal as well


Calva defaults to using the latest version. And yes, printed in the Calva says output channel at startup.


It says latest. I cleared cache and restarted vscode, still the same.


i can help you debug this if you tell me what to look at. i literally installed vscode for the first time on friday so i have no idea how any of it works


When clojure-lsp has started Calva reports the version used. latest is rather the setting.


ah, that! clojure-lsp 2021.09.30-15.28.01 clj-kondo 2021.09.25


the unresolved-var linter is a linter from kondo that If contains cache about that namespace it checks if the function is known or not, running clj-kondo manually only in your project, will make clj-kondo known only your namespaces and not the external dependencies, but with clojure-lsp it scan both


I suspect you have a really unresolved-var 😅 could you share your code? or make a tiny repro with the issue?


(ns lsp-repro
  (:require [clojure.test :refer :all]

(deftest repro
  (testing "aleph.http is required..."
    (with-redefs [aleph.http/post (constantly (future {:status 200}))]
      (is (= 1 1)))))
if i explicitly :refer [post] it, it then complains about it in the require as well.


looks valid to me, but I don't know what is post in that namespace, could you make a minimal repro in a repo? so I can test it as well


def-http-method is a macro and clj-kondo doesn't know it defs a symbol in this case


you need to configure it via clj-kondo configuration, more details here:


i need to do that config for an external library? 😮


probably adding this to your .clj-kondo/config.edn will solve it:

{:lint-as {aleph.http/post clojure.core/def}}


unless that library exports clj-kondo config, yes


and I think this lib doesn't


you can open a PR on that lib to export the clj-kondo configu, similar to this lib:


alright i'll consider doing that


@UAEH11THP I just remeber clojure-lsp has a action for that


on another note though why does it work when running clj-kondo standalone?


if you apply the code action resolve macro as


sorry i don't know what a code action is?


in calva I think the shortcut is ctrl + . ?


i'll go read the docs haha


@UAEH11THP With your cursor over the macro you can try running the Calva command “Resolve macro as” (ctrl+shift+p brings up the VS Code command palette and you can search there for it).

👍 2

Is it possible to by default unfold the outline entries?


No idea. ¯\(ツ)


A quick settings search says there isn’t.

Fabricio Cozzarolo19:10:59

hello guys! i noticed the last version changed rainbow colors in VSCode.... is there a way to get the old ones?


It did? Hmmm, is rainbows part of semantic tokens, @UKFSJSM38?


nope, semantic tokens don't touch on parens


if so, it could be a issue on vscode-languageclient lib


or in Calva if it create the rainbows manually


Yes, Calva creates the rainbows very manually. But zero changes made there. Have you activated the built-in rainbows, maybe, @U02EDDCK800?


VS Code recently implemented rainbow parens natively -- and after the last Calva update, things did look a bit different to me. Let me double-check my settings (since I thought I had turned things off in Calva since the native stuff was added).


The native stuff is fast and all, but not as Clojure aware as Calva’s. So I def think Calva wins as long as you are not editing some huge EDN (in which case Calva croaks anyway).


I turned off the Calva highlight indent and that seems to have resolved whatever weird conflict I was seeing -- even tho' the built-in stuff isn't as good as Calva's, it's wicked fast and the speed is more important to me than the look TBH.


Did you experience slowness with Calva’s rainbows? You really shouldn’t have…


I'd say it "contributes" to some lagginess overall but it's hard to point to just the Calva stuff and say, yeah, it's slow. We certainly have a few large files with a lot of nesting where the shifts in bracket color as you type is "noticeable".


Interesting. And you didn’t tell me! 😃


It is noticable if you have large structures, though. That is a known fact. For normal Clojure functions, even large ones, it shouldn’t be. It’s single digit milliseconds, allowing for 6o FPS even on quite slow machines.


This is good for someone running with Calva’s rainbows to know. If they turn slow for Clojure code, I want to know.


We have had a discussion about this but it wasn't a big deal -- and like I say I can't definitively point at this specific feature of Calva and say it is slow. But all these things contribute a little.


If I could identify a specific file where just this specific Calva feature could be clearly seen as a problem on its own, I'd share the file with you 🙂

💪 1
Fabricio Cozzarolo20:10:44

may be i expressed myself wrong... i meant by rainbow both the parenthesis and the symbols.... before update i was seeing the keywords in blue and after that in purple. i guess parenthesis are equal than before. i haven't changed anything in vscode config.... but now you mentioned could it be a vscode update that's causing the change?


Now it makes sense, yes, this is indeed semantic tokens and it's using the default tokens of vscode for your theme (which I think it makes sense), if Calva wants to customize that it's possible as well

Fabricio Cozzarolo20:10:00

i can barely notice that when i open a file it has blue keywords and changes very quickly to purple... i guess that's an styling config overriding calva's one?


yeah, maybe it's a good idea calva customize the keyword one to be similar to when there is no semantic tokens so this flash would not happen


I don’t think there is a way for Calva to customize this?


But how should Calva know what some theme will be using?


it doesn't need to, you just say "use keyword color for this kind of token"


For example, this is how Dart/Flutter vscode extension is doing:


Ah, that explains what I thought I was seeing today (after the Calva update): keywords changing color. But I wasn't sure whether it was just doing it slower than before or something had actually changed.


So what is “this kind of token” that I should say use keyword color for?


the token returned from clojure-lsp, which I think is "keyword"


Is Calva's highlighting something we can disable?


(for me, keywords seem white by default and switch to purple when Calva catches up which is pretty distracting)


Nope. Calva provides the language grammar for Clojure. You can only disable the extra highlighting done, like rainbows.


You can either disable semantic tokens or wait for us to solve the most glaring flicker issues.

☝️ 1

I just need to understand what I should do. So far I don’t get it at all. I should map from something to something, but both those are unknowns for me. I stare at that config and don’t know what is being mapped to what. 😃


                   "keyword": [
What on earth could that be doing?

Fabricio Cozzarolo21:10:17

the flicker is because vscode style is delayed or the inverse is happening?


hahah, about vscode me too 🤷 what I know: server return tokens following the LSP spec, for example for :some-foo clojure-lsp returns that token is a keyword , now client can apply a different highlight for that token, for example:

keyword": [
this means color the keyword tokens with the vscode "" whatever this means in vscode haha


@U02EDDCK800 First the built-in (Calva’s) style is there. Then the semantic tokens from clojure-lsp kicks in.

❤️ 1

AFAIK "" means a color for a function member of the current vscode theme, which could be white for a theme or red for other


“property declaration” is a semantic token?


Therefore, we just need to know what vscode highlighting the Clojure default uses and make the 1:1 for semantic tokens


I know exactly what the clojure defaults are. I wrote them. 😃


Good! so you will know better than me what to use :) this is the table for semantic tokens:


And you wrote the semantic token stuff. Between us we should be able to fix this.


you just need to remap for those you want to change


> And you wrote the semantic token stuff. Between us we should be able to fix this. Yes !


That table is nice, but I’ll need to know what clojure-lsp is using for what clojure construct. Then map to what the Textmate grammar is using for the same construct.


you can easily see that with the LSP command cursorInfo :)


Also, the textmate grammar does not so far distinguish between alias or ns and symbol. So we won’t be able to map this fully.


@U0ETXRFEW I think the biggest differente ATM is the keywords and macros/functions only


mapping those should remove almost all blink


I don’t know how to run that lsp command.


Should I add the command to Calva?


I think Calva only implements the serverInfo


yes, just follow the same @U9A1RLFNV did for serverInfo


So, you can’t just tell me instead? 😃 .


haha there is nothing special, you just need to call the lsp command cursorInfo with your cursor on the symbol you wnat to get info :man-shrugging:


how to call that command on Calva/vscode, I'm not sure


that's why I suggested checking how @U9A1RLFNV implemente it on calva for serverInfo


Yes, I can implement that command. Seems like a lot of work where you could just tell me instead. But maybe there is something I don’t get here still.


I can say what tokens clojure-lsp return for a specific code as well, is just that if you want to change too much things the safest would be to check what clojure-lsp return


but for a piece of code or another I can help :)


Actually I don’t need to add this command to Calva. VS Code has something built in:


that's what I thought and that's why I told to use the command, nice!


oh this is not the command, looks a nice vscode thing


Yes, but it is showing funny stuff for the textmate scopes…


But that’s all my. own fault. I wanted defs to look special. Which they don’t do any longer with semantic tokens, so I got confused. Hmmm. Maybe we should disable semantic tokens until we (well I) understand what’s going on better. Right now it feels like I lose control over Calva’s UI/Ux.


Sure, Feel free :)


FWIW, I changed Settings > Editor > Semantic Highlighting: Enabled to false and that "solved" the problem. /cc @U02EDDCK800

🙌 1

It would be nice to have it configuredByTheme and not have Calva mess with it but... 🙂


Don’t know what you mean with configuredByTheme? The themes only provide the looks, right?


Actually you should be able to just set it to configuredByTheme and that should fix it as long as your theme does not have semantic token support.


It was configuredBytheme -- that what caused the conflict with Calva.


(well, once LSP got updated)


I can do a screenshare with you, if you're interested?


I see it on my machine. 😃 I just don’t frame it as a conflict or Calva messing with anything.


If you tried it with a clojure-lsp only extension you would see the same thing. With Calva at least we have the possibility to soften the flicker.


Given that, with that setting as false, I see variables (symbols) and keywords as white -- is that Calva's default colors? And when I enable that setting and see variables (symbols) and keywords switch to light blue and purple respectively, that's the theme's semantic highlighting, driven by LSP? So the "lag" is with the running of LSP and the editor changing the code colors to match?


Calva doesn’t have default colors. But, yes. Otherwise I think you summarized it like I how I understand things.


What we can do is to tell VS Code that when Calva has given something scope X it is to be treated by the theme the same as semantic token Y.


Then the theme would render things pretty similar in the two systems, and the only change we would see is when the semantic tokens are richer in their understanding of the code than the textmate grammar is. E.g. clojure-lsp knows when something is a macro, so we can have that show once LSP has provided the info.


Currently, does Calva set symbols (such as local bindings) and keywords to the same "color" or are they semantically different?


Actually it doesn’t. It is your theme that colors them the same.


(with semantic highlighting, they are different colors, but I haven't managed to find a theme where they are different colors without semantic highlighting -- which is why I asked)


For me they color different with bot Light + and Dark +, as well as with the Github themes.


Is that with that semantic highlighting enabled? Or disabled?




Semantic tokens changes everything. 😃


Interesting. Let me check my settings…


With semantic highlighting ENABLED (configuredByTheme):


Pale blue symbols. Purple keywords. Also and -- a macro -- changes from yellow (like a function above) to blue.


All of those could be changed on calva (or clojure-lsp if clojure-lsp is returning a really odd token )


That's on macOS if it makes a difference. Latest VS Code, latest Calva, latest LSP.


How did you get all those settings on the same screenshot?


I filtered settings by theme


I prefer the different colors so I'll probably keep the configuredByTheme semantic tokens enabled and live with the laggy change in colors.


Here’s what it looks like on my mac.


Maybe you have some other Clojure extension that provides highlighting grammar?


I am pretty sure I do not.


Clover doesn't contribute highlighting.


Do you perhaps have anything custom in your settings.json file?


Nope. Only thing in that direction I have is

"workbench.colorCustomizations": {
        "terminal.ansiRed": "#ff7a5a"
Which I can recommend. Makes error text readable in the terminal.


I don't use the built in terminal for anything 🙂




what's the issue with @U04V70XH6 when disabled? I checked the print but I couldn't figure it out


@UKFSJSM38 with semantic highlighting disabled, symbols and keywords look the same (white -- in the dark+ theme); with semantic highlighting configuredByTheme, symbols and keywords look different (pale blue and purple respectively)


Compare with my screenshot and you should see it.


got it, that's really odd, my vscode with disabled semantic tokens looks the same of @U0ETXRFEW


Yes, I have not seen that issue before.


FWIW, the colors are exactly the same on my Windows/WSL2 setup -- which has settings/extensions sync'd with my Mac.


(and the behavior with semantic highlighting disabled vs configuredByTheme is identical too)


@U0ETXRFEW you showed how to get VS Code to tell you what a symbol is/what styles are applied to it? What was that? Maybe I can debug why I don't see blue keywords locally?


Command palette -> Developer: Inspect Editor Tokens and Scopes


OK, here's what I see for a keyword (white -- semantic highlighting disabled):


And here's what I see for a local sy,bol:


The default theme colors keyword the same as symbol which is why Calva’s grammar uses the scope variable.other.constant.clojure for keywords. Not happening for you, but anyway.


I disabled all my other extensions and keywords turned blue 🙂 So now I just need to figure out which one is causing this...


There is an extension disect feature I think…


Ugh! It's something in Clover, apparently. I didn't think that contributed anything to code coloring 😞


I don’t think it does. Not directly. But it might trigger the built-in Clojure extension to provide its grammar.


Not at all sure about this, but the built-in extensions are special.


We can win over VS Code if @U3Y18N0UC picks up Calvas textmate grammar json and places it in Clover. 😃 We will need to sync now and then when we update the grammar, but that is very seldom.


For now you could disable syntax changing in clover? Is there any setting to disable that in clover?


Probably not. Clover is not contributing syntax, I think. This is VS Code being stupid.


Hey @U0ETXRFEW, just tell me how to do it and I'll do 🙂. I'm quite unfamiliar on how to make this things work...


Hi @U3Y18N0UC! 👋 🙏


Calva has this in it’s “contributes” map in the manifest:

"grammars": [
                "language": "clojure",
                "scopeName": "source.clojure",
                "path": "./clojure.tmLanguage.json"


If Clover has the same and you pluck out the clojure.tmLanguage.json from Calva, I think it won’t matter which of the extensions wins the race.


(! 676)-> find ~/.vscode/extensions -name clojure.tmLanguage.json


Ah, so maybe Clover does provide grammar?


I copied Calva's file to Clover's install and problem is solved! 🙂

🎉 1

Aha 😃


There were quite a few differences in patterns and what they resolved to.


I think it is best to also provide that piece in the manifest.


@U3Y18N0UC So I guess the Calva version of the textMate grammar is more recent than Clover's? (and maybe Chlorine's too?)


Clover has

"grammars": [
				"language": "clojure",
				"scopeName": "source.clojure",
				"path": "./clojure.tmLanguage.json"


I just didn't see it in VS Code's list of what an extension contributes...


I see. Well, then a solution is to remove that. Depends. But it might be super similar to the VS Code built in one (which is built from Atom’s default Clojure grammar), so removing it would make things look the same for Clover only users, and let Calva + Clover users have Calva’s.


Haha, well, maybe there was a very good reason. But also maybe it is a remnant from when @U3Y18N0UC and I tried to bring over some Calva static things to Clover.


For now I have a solution, until Clover gets updated.


A night full of TILs for me here.

😄 1

Anyway, lots of threshing from my side. But knowing what we now know. Just refreshing Clover’s copy of the grammar file might be the way to go, @U3Y18N0UC. It has since been removed from source control, but it’s there in the Calva extension folder.


There’s some Calva prompt shenanigans in the grammar, but it’s quite tricky to type the prompt manually so should not cause any troubles.


Code-wise LGTM


@U02EDDCK800, @U04V70XH6, can you test this VSIX and see if it makes most of the flicker go away? Let me know which things still change visibly, and we might be able to fix some of those too.


Big improvement! Keywords "stay" blue, local symbols change from white to pale blue.


Macro invocations switch from yellow (function-like) to blue (per known, built-in macro usage like let, if etc).


(I tested with Clover disabled, just in case that might affect Calva's grammar/highlighting but it doesn't seem to now that both are the same)


Also, aliases in qualified names change from yellow to green (at least in a function call -- where yellow is the default for a function call).


This change should be the same with our without Clover as long as you have copied that grammar file. I didn't update the grammar, just provided a mapping from semantic tokens to grammar scopes. It took me quite a while to understand the concept, but now it makes sense to me. 😀


The local symbol change is a bit jarring but white to pale blue isn't too bad. The other changes are fine.


Some changes are inevitable. Not sure if we can fix the local symbols. It's probably jarring in some themes...


If you examine the scopes and tokens, maybe you can see if a mapping can fix it. I'm afk now.


Yeah, I understand that some semantic changes are always going to be delayed until LSP has had a chance to run. I'm at the end of my work day here. Might look at it tomorrow.


Me too! Talk tomorrow. Thanks for all the help!

Fabricio Cozzarolo01:10:34

changing Settings > Editor > Semantic Highlighting: Enabled to `false` worked for me too, it looks exactly the same as before. 😃


Ok, so what should be the best course of action here? Do I remove the clojure.tmLanguage.json or do I update with the Calva's latest version? WDYT @U0ETXRFEW @U04V70XH6? I have to say, I'm still grasping all these "grammar" and "VSCode API" things, so the answer for "why things are like this" will probably be "because that's what worked at the time" :rolling_on_the_floor_laughing:


Haha, yes, it’s a lot like that. 😃


Let’s see. Clover probably has two categories of users: 1. They use only Clover 2. They use Clover together with Calva, possibly inspired by @U04V70XH6’s config, and by that proxy clojure-lsp. If you remove Clover’s grammar contributions, category 1 will get VS Code default Clojure syntax highlighting. And category 2 will get Calva’s + clojure-lsp add-ons. If you keep the grammar contrib, category 1 will get Calvas syntax highlight, and category 2 will get Calva + clojure-lsp.


I think that points at removing. The differences between built-in and Calva’s highlighting are maybe not big enough to carry the extra maintenance burden.


Ok, I'll remove it 🙂. Thanks for the help!


Published today a new version of Clover without the grammar contributions, so it'll play nice with Calva 🙂

🎉 3