Fork me on GitHub

Do we have an unused variable/argument highlight feature in calva?

(defn foo [a b c]
  (prn a b))
in this snippet, c is an unused argument so it should be highlighted
(defn foo []
  (let [a 5
        b 6
        c 7]
    (prn a)))
here, b and c are unused variables so, it should be highlighted in some way to indicate that. I think cursive has this feature. Happy to file an issue if it’s not supported yet.


If you have LSP active, this should be flagged @pratikgandhi1997 -- it is flagged for me as an unused variable.


if you have clojure-lsp properly active and running it will warn that indeed as @seancorfield said


LSP/clj-kondo flags the lack of docstring (for a public var), foo for being globally unused, and c in both functions and b in the second function as unused.


(the first one is a linter I have turned on -- it's off by default)


For me, it’s only reporting foo being globally unused, looks like I have overridden clj-kondo settings somewhere, thanks for the response


the possible locations could be ~/.config/clj-kondo/config.edn ~/.clj-kondo/config.edn (legacy), project/.clj-kondo/config.edn


~/.clj-kondo/config.edn never worked


unless you didn't have a .clj-kondo in your project and it accidentally picked up that one

☝️ 2

Awesome! I will look at my project level configs


@U04V15CAJ maybe clj-kondo should exclude ~/.clj-kondo/config.edn to avoid confusions because of projects that doesn't has a .clj-kondo dir?


(It look a long time for me understand this corner case, whole nubank was using that way until we understand that corner case 😂)


do we explicitly need to mention unused-binding in config.edn ? or the default setting is set to error


default is warning I think


it works when I delete my config.edn and reload the project, but when I put it back, it stops working, it doesn’t have unused-binding option by default…..and it starts with

^:replace {:linters {...}}
does it overrides all the default settings? I was going through and think that it shouldn’t but somehow in my case looks like it’s overriding the not mentioned settings


yes, this replaces all default config


so this is why you don't get unused bindings anymore


just don't add ^:replace


Yup, this works 👍


thanks a lot!


I meant to ask: how many folks have turned off Calva's rainbow brackets and enabled the new built-into-VS-Code high-performance bracket colorizer?


The default built-in colors are a bit bright but I love that I now get rainbow brackets in all files -- even markdown!


I haven’t tried, but I somehow doubt that the built-in coloring could be as good with Clojure as Calva’s. And also if you use Calva’s indent guides, they will be out of sync with the colors of the brackets… I’ll give it a try now.


It depends a bit on preferences of course, but anyway, Calva colorizes reader tags, quotes and other things that “belong” to the opening bracket the same way as the bracket:


The cursor wasn’t caught in the screenshot, but it was before #z. Hence the active indent guide showing that the current enclosing form is (c …) using the same color as the brackets for that form.


The same using these settings:

"calva.highlight.highlightActiveIndent": true,
    "calva.highlight.enableBracketColors": false,
    "editor.bracketPairColorization.enabled": true, 


Note that the first screenshot was with these settings

"calva.highlight.highlightActiveIndent": true,
    "editor.bracketPairColorization.enabled": true,
So you would still have bracket coloring in Markdown files, etcetera. This can get a bit crazy in diff views where the built-in colorizer is enabled in both panes, gets overidden by Calva in the right pane and thus the colors does not match up. However, that can be dealt with by either theming the built-in colors to match Calva’s or to set Calva’s colors to match the theme/default colors. Calva’s default colors are:
"calva.highlight.bracketColors": [["#000", "#ccc"], "#0098e6", "#e16d6d", "#3fa455", "#c968e6", "#999", "#ce7e00"]
Where the first entry is a tuple: [light theme, dark theme].


Is this built-in highlighting related to the semantic tokens LSP feature that @UKFSJSM38 mentioned?


Good question. I have no idea. I'm baffled by the performance, though. It's crazy.