You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: