Do you mean you want these two vars to be highlighted/colored differently?

(defn hello [name]
  (str "Hello " name))

(def user-key :product/user)

hello and user-key?

If so, I’m not sure if that’s possible but @U0ETXRFEW knows more about highlighting. Maybe there is some way to customize it.

I think that clojure-lsp could do it. Calva doesn’t collect this information.

You may want to ask in #CPABC1H61. It provides semantic highlighting for Calva when it’s running for a given project.

You can show the hover using the keyboard, @U06KD64RX. FYI. It’s cmd+k cmd+i on Mac.

What’s the reason behind that “best practice”, btw? If I am allowed to derail the discussion, now that we’ve determined that the question should be asked in #CPABC1H61, anyway. 😃

Yeah, at least with clojure-lsp support, keywords can be treated as symbols in terms of finding references and renaming, so I don’t see the benefit from a tooling perspective. Maybe it’s more about reducing bugs caused by keyword typos, and/or something else.

I can't think of any negative against capturing whatever knowledge clj-kondo is already able to garner about the types (string, number, keyword, function, etc.) underlying symbols, and translating that to additional scopes in the grammar. (If not clear, I would expect to still also see the current more-generic scope) Users could then optionally extend themes to their hearts' content to display those differences.

Indeed. It would probably not make a difference for someone not using an aware theme.

@U90R0EPHA yes definitely, extending it even further would not be a downside at all (since it's fully opt-in), and a massive upside for those that want/need it.

@U9A1RLFNV @U0ETXRFEW thanks for the suggestion of posting in #CPABC1H61, that seems more appropriate when I think of it as well 🙂 but thanks for a good discussion!

@U0ETXRFEW more a tongue in cheek way of describing it, since noone ever agrees on Best Practices. that's why I wrote them in quotes (ironic quotes should be its own utf-8 maybe 😄)

Oh yeah. An air-quotes emoji would be great. ...Though I don't think anyone on the Calva team is a member of the Unicode committee. So maybe not the right place for that suggestion? 😉:rolling_on_the_floor_laughing:

The idea makes sense, but I can't see how we would make that work reliable. LSP (and clj-kondo) use static analysis, so no runtime information, how could it know these are keywords:

(def my-key-def (keyword "foo"))

(def my-other-key-def (if *something* :some-keyword "not-keyword")

I don't think that possible difficulty in reporting the type of (def foo (keyword bar)) should at all stand in the way of reporting the type for (def foo :bar)). Although in that specific example (def foo (keyword bar)), the type can be statically analyzed quite accurately as keyword-or-nil (ignoring throws-an-exception cases). And your second example is a keyword-or-string. Depending on how much work it is to get clj-kondo to inform of that, I think sum types could be reasonably up for grabs too.

That is trying to emulate runtime from static, it's not assertive and those are a few examples of lots of possible others that would make it hard to know. I think it's something that is not worth it unless @U04V15CAJ sees any other way, maybe he can give his opinion as well

can you summarize the question?

The feature request is something like: > Make clojure-lsp provide special semantic tokens for symbols that represent keywords. And the question would be if you see a viable way to know if a symbol does that. (I think).

a symbol that represents a keyword?

you mean like:

(def a ::foo)

yes, check https://clojurians.slack.com/archives/CBE668G4R/p1684159628898339?thread_ts=1683901868.167329&cid=CBE668G4R

this is not something suited for static analysis

OP was hoping to color highlight symbols that point to keywords. And I expanded on that to suggest creating grammar (highlighting) scopes for the underlying types of all symbols that clj-kondo essentially should already know the type from the static analysis that is already being run anyway.

> this is not something suited for static analysis That brings the feature request back to Calva or nREPL, I think.

is it just about the type?

yes

yeah that would be possible, I guess

but how common is it really that someone does (def foo ::foo) and then uses foo in multiple places?

Appearantly “best practice” (scare quotes) in the @U06KD64RX’s project. 😃

> but how common is it really that someone does (def foo ::foo) and then uses foo in multiple places? > I don't know. But magic numbers are certainly common, or urls created as config, and used across the app. In my suggestion, keyword would just be one possible type available to know.

@U04V15CAJ @U0ETXRFEW 😄 yeah we actually do that a lot, but definitely not common-law Best Practice™ (yet…), or this would have been implemented long ago I guess. I'm very heartened by the rich discussion about the topic, so a big thanks to everyone for that. very interesting to get more insight into if this is a) possible at all, and b) feasible enough to actually do.

I think it is clojure-lsp doing this. Could be clj-kondo, but I seem to recall that this particular linter is from lsp. You can try deleting both .lsp/cache and .clj-kondo/cache and restart clojure-lsp and see if that helps.

Maybe because you are trying to use an unqualified tag? > Reader tags without namespace qualifiers are reserved for Clojure. > --https://clojure.org/reference/reader#tagged_literals > What happens is you change it to ... ?

{foo/my-obj my-ns/my-fn}

> What happens is you change ... Same "warning":

I created a repo here: https://github.com/jacobemcken/lspbug

Ping @UKFSJSM38

Yep, LSP bug, since data readers is not really a normal clojure file, it has a namespace without requires, I'm not sure if we can fix only in clojure-lsp, we would need clj-kondo analysis for the val in that map, @U04V15CAJ does clj-kondo emit analysis for data readers files?

?

I mean: src/data_readers.clj

{my-obj my-ns/my-fn}

Hmm, not sure.... let me check

navigation works for me in this example:

src/data_readers.clj

{f/foo clojure.core/vec}

I do get an unresolved symbol for f if it's not qualified which might be a bug, but it's not recommended to use unqualified symbols there anyway (should be fixed tho)

when I hover the symbol in data_readers.clj I get "LSP internal server error" when it's something custom and not a clojure.core symbol

yeah me too, I just tested and there are no analysis for data_readers.clj :thinking_face:

you can confirm running lsp-clojure-cursor-info , it show the analysis of the cursor that kondo returned for LSP

ahh, only for clojure.core symbols there are analysis, for custom user namespaces no, so it seems that is missing in kondo

please make a repro (+ issue if applicable)

sure!

ah right, I think I know what's the issue, since clj-kondo doesn't regard those namespaces as already required, it does not regard those symbols to refer to vars

issue welcome

https://github.com/clj-kondo/clj-kondo/issues/2079

thanks. I hope to release a new clj-kondo on Wednesday. If I don't get to it before then, PR welcome

You guys rock! 🎸 :the_horns: