Fork me on GitHub
Yuner Bekir06:03:03

Hello guys. My keywords color changed, they were blue. Other colors changes as well. I know there is a setting for the colors but I cant find it.


They are now tokenized as clojure keyword constants. Some themes don't have a rule for keyword constants. You use the editor.tokenColorCustomizations setting and target them with the scope ["constant.keyword.clojure"] . Example:

"editor.tokenColorCustomizations": {
        "[Default Dark+]": {
            "textMateRules": [
                    "scope": [
                    "settings": {
                        "foreground": "#6fbfff"

Yuner Bekir07:03:16

I use the default dark theme. I will try your example. Thanks ❤️


I guessed you were using the default dark theme, hence the example. 😃 I can recommend the theme Github Dark Default, btw. It's very complete and nice.

Lukas Domagala17:03:08

I like dark+, which is also a default theme but handles more token types


This is dark+, which doesn't handle as many tokens as GitHub theme, afaik. :face_with_cowboy_hat:

Lukas Domagala22:03:58

mine does handle keywords and stuff. githubs purple is too much for me 😛


Which dark+ are you using?


My Dark+ (default dark) today:

Lukas Domagala13:03:38

Yeah mine looks the same. It’s default as well but I’ve tried a few and either their main color is too bright (the github theme, night owl …) or they don’t have enough tokens defined. Dark+ has been the best which is actually nice for a default theme.


I think that the glitchy behaviour of Dark+ sometimes having highlighted keywords and sometimes not, is that it is clojure-lsp applying semantic tokens. And when clojure-lsp stops working, as it often does in my work project, then no highlight for me. Whereas Githubs theme has support for the keyword constants at the textmate scope level.

Yuner Bekir15:03:22

Another issue I noticed is that unused symbols don't get marked differently. That was not the case till recently. I tried the github default dark, its the same there


That's probably unrelated to the theme. It is clojure-lsp that is figuring out what is unused (or rather clj-kondo). It could be the same root cause as what makes keyword not highlight correctly though. If you have more projects, you can check if it is the same in all of them or just some.

Yuner Bekir06:03:12

The behavior is the same. You mentioned clj-kondo and I checked if I have anything in the problems tab on the terminal. It was empty, there are usually a lot of problems. This makes me think that clj-kondo has stopped working. If memory serves me right it should come bundled with calva. Is there a way to turn it on manually?


The linting is part of clojure-lsp, which uses clj-kondo. I think the clj-kondo version is tied to the clojure-lsp version, maybe @UKFSJSM38 can confirm. If so you can try specify an older release of clojure-lsp and see if that helps. Also check in #lsp for advice.


Latest clojure-lsp use previous stable clj-kondo, I really doubt that is the issue


Sounds like a format error. In emacs, the following code formats well

(-> (get-in [:body :result])
    (as-> x
          (> x (nth @height 1))
          (swap! height (fn [[_ end]] [end (inc x)])))))))
but in Calva, it becomes
(-> (get-in [:body :result])
    (as-> x
            (> x (nth @height 1))
            (swap! height (fn [[_ end]] [end (inc x)])))))))


It formats like the first example when I try it. Do you have a custom format config?


Potentially will that config bury at?


Here is my calval-fmt setting:


Do you see any error in the dev console when formatting this?


The code is not balanced, btw. But maybe that is just the piece you've copied out?


Yes. That’s just the piece I copied.


I see no error.


For example, this simplified code also does not work:

(-> d
    (as-> x
          y w w2))


Does it format like that, or does it not format at all?

Lukas Domagala17:03:40

I also get the same format as @UGC0NEP4Y, but I thought that is the correct way to format it, where args are on the same indent level


Ah, could be that I was testing with a customized setting. Maybe we should start with checking cljfmt defaults. 😀


Not sure how to achieve the formatting you ask for there, @UGC0NEP4Y, since it is using three spaces for as->, but to follow the community style guide better you can use [[:inner 0]], which will give you two space indents.


> I also get the same format as @UGC0NEP4Y, but I thought that is the correct way to format it, where args are on the same indent level The format of as-> inside (->) ignores the implicit parameter injected by ->.

Lukas Domagala13:03:01

Does emacs use cljfmt as well? This feels like a problem that has to be handled there


Emacs formats fine, and I originally thought emacs uses cljfmt so it might be an issue for Calva.