Open vemv opened 1 year ago
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.
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:
::foo
means:some.ns/foo
::foo
,::bar/foo
,:a.b.c/foo
, depending on the contextLeaving it here for the hammock.