@borkdude did you see tree-sitter? https://www.youtube.com/watch?v=Jes3bD6P0To, maybe it’s interesting to clj-kondo somehow

I haven't seen it, but added it to my watch list. Thanks!

Some very cool stuff going on there. To provoke some more interest: the system they built can parse code incrementally, maintaining a full syntax tree by incorporating edits from the user as they come in. It can also parse invalid code, recovering from syntax issues in subtrees/leaves of the AST.

It seems LSP can also do that (parse incrementally)

Yeah, he also references LSP but considers that both complement each other, tree-sitter sitting at the super low-latency spectrum needed for anything that requires “as you type” kind of interactivity

true, I guess LSP is only a high level protocol. using LSP you can pass the text to a parser, which could be tree-sitter

LSP is considered too high latency for the things tree sitter is achieving. E.g. Syntax highlighting

I guess it depends what you're doing with your LSP events. LSP itself is just a network/REST thing using JSON, which is fast.

How do they define low latency, which threshold in ms are we talking about?

I guess 60fps? i.e. double digit ms

(in an ideal world 😛)

> - The LSP probably isn't well suited to general syntax highlighting due to computation cost and communication chattiness concerns, but the LSP may eventually support semantic syntax highlighting [1]. This could, for example, allow an editor to color all singletons hotpink, which requires a semantic understanding of the code. Semantic highlighting would augment the base highlighting provided by tree-sitter or by a TextMate grammar. Syntax highlighting targets instant. as plugins will be using it to make decisions.

10k loc buffer needs to be re-sent and received on every change with LSP IS implied.

Editors can implement the incremental part based on their buffer data structures to provide instant highlighting

The key thing here is that most toolchains aren't incremental by default.

@dominicm LSP can send incremental changes

I think that the implied problem is that most compilers aren't capable of handling incremental changes. Maybe they are stateless, or simply not designed that way because it isn't useful for their language.

it's definitely harder. kondo doesn't support it 😉

kondo does try to stay within double digits latency though for single files

if the linter becomes too slow that's also feedback: split up your file in multiple namespaces 😛

Sometimes there's no real logical way to do that.

E.g. A model layer for a graph database. You can't split by entity, because your queries operate across many of them.

incremental compilation is a very interesting research field

@dominicm it's kind of a similar problem that clj-kondo has I think. I do that by passing main functions as arguments to sub-functions. it's a bit of a hack maybe. clojure.core does it with in-ns I think

(I also tried in-ns briefly, but it's less linter-friendly and also it gave weird problems with graalvm / AOT)

also multi-methods may help there

I don't understand at all, sorry

Splitting in multiple files can be achieved with multi-methods, passing functions around as arguments or using in-ns

unless I don't understand the problem you described, then I'm sorry 😉

Oh, I just meant that it is sometimes unclear in which dimension to slice up a namespace.

@borkdude how do I find all (:require [...]) in my src/main ?

@souenzzo You mean all referred namespaces? What is the background of your question?

I want to programmatic access all :requires in my project I will use it to create assertions like datomic.api should always be aliased as d or do not use refer inside my test suite

@souenzzo you might like this new feature: https://github.com/borkdude/clj-kondo/blob/master/doc/config.md#alias-consistency

and for doing stuff manually, you can use https://github.com/borkdude/clj-kondo/blob/master/analysis/README.md

"do not use refer" isn't included in the analysis data, but it could be an option for the alias-consistency linter maybe

maybe that data could also be added to the analysis data

the relevant data is now in :namespace-usages