Let me think through the use cases here... sorry if I'm repeating what you both discussed already. It seems the benefit here is to be able to do go to definition
. There is also find reference
, but I think that's covered just by having analysis return all keywords and where they are found correct?
For go-to-definition
we need to know which of the many places the keyword is used in its canonical definition
. Figuring out what is canonical is the hard part. Ya, I can imagine if you can teach clj-kondo what functions or macro forms where a keyword appear is the "canonical definition" for it. That would be neat actually.
Like @borkdude said, its possible more than one thing define things with the same keyword. So I'm guessing it needs to be each keyword can have 0 or more definitions. And the editor needs to support listing multiple choices when you do go to definition
. I can do that in Anakondo easily, not sure if LSP supports this?
Now there's the issue of when things are defined dynamically, so now where do you go? Can clj-kondo be smart enough to learn about those as well, and give us the place where the keyword will get dynamically defined? That's what you meant by supporting hooks
for it @borkdude?
And a nice linter for this would be that say if you are inside of a spec function, and you use a keyword that is not defined anywhere it warns.
Something else I'm thinking, on a similar vein, it be nice if when auto-completing keywords, it could show only keywords that are relevant. So if you s/def
some keyword, and then you s/validate
like only keywords that have been s/def
should show up in the auto-completion. Just thinking how to do this...
Also, why not make it a separate entry like var-definitions? Maybe I understood wrong, but it sounded here you wanted on keyword-usages to add a :def
key?