Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

xref-find-references for keywords #181

Open
vemv opened this issue Aug 28, 2023 · 1 comment
Open

xref-find-references for keywords #181

vemv opened this issue Aug 28, 2023 · 1 comment
Labels

Comments

@vemv
Copy link
Member

vemv commented Aug 28, 2023

One often can wonder "where is this keyword used?". Especially (but not limited to) ns-qualified keywords.

So our existing xref-find-references functionality could be extended to support keywords, based on simple source code analysis.

It would be our first xref-like feature that would support clojurescript.

And also, I believe, one of our very first features using a more comprehensive static source code analysis (e.g. traverse many files in search of matches), with all it takes (performance, caching etc).

I wouldn't want to create our own clj-kondo/clojure-lsp style local databases - those projects are much more refined than what one could handroll of a one-off feature.

I'm thinking of something in-memory, parallel, maybe backed by a LRU cache.

Normally, keyword search is limited to a project, so we can take advantage of that to quite greatly limit the search corpus (maybe to the extent of not needing a cache. IDK).

So, in a way, this would be like a glorified grep, except that it understands keywords better:

  • for the input parsing, it understands that our query of ::foo means :some.ns/foo
  • while searching a given ns for matches, it knows to search for any of ::foo, ::bar/foo, :a.b.c/foo, depending on the context
  • matches are exact (grep can struggle when a given keyword is a subset of a longer keyword)

Leaving it here for the hammock.

@vemv
Copy link
Member Author

vemv commented Aug 28, 2023

One quick idea is that the cache could be rather small by design - instead of caching large data like slurped file contents, or an AST, etc, we keep this simple mapping:

  • ns -> <keywords used by that namespace>

e.g. {my.ns [:bar/baz :quux/quuz]}

So the whole cache for a given project would be a quite tiny hashmap.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant