This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (13)
- # beginners (51)
- # boot (3)
- # calva (10)
- # cider (20)
- # clj-kondo (55)
- # cljs-dev (60)
- # clojure (99)
- # clojure-europe (6)
- # clojure-gamedev (9)
- # clojure-italy (19)
- # clojure-nl (7)
- # clojure-spec (20)
- # clojure-uk (42)
- # clojurescript (96)
- # clojurex (37)
- # clojutre (1)
- # cursive (37)
- # data-science (2)
- # datomic (15)
- # defnpodcast (9)
- # duct (7)
- # emacs (6)
- # events (10)
- # fulcro (124)
- # jackdaw (4)
- # jobs (4)
- # leiningen (9)
- # malli (7)
- # mount (3)
- # off-topic (167)
- # other-languages (8)
- # re-frame (39)
- # reagent (4)
- # reitit (6)
- # remote-jobs (2)
- # rewrite-clj (36)
- # ring (4)
- # shadow-cljs (16)
- # spacemacs (16)
- # tools-deps (91)
- # vim (8)
- # yada (2)
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.
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.
> - 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 . 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
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.
if the linter becomes too slow that's also feedback: split up your file in multiple namespaces 😛
E.g. A model layer for a graph database. You can't split by entity, because your queries operate across many of them.
@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)
Splitting in multiple files can be achieved with multi-methods, passing functions around as arguments or using in-ns
Oh, I just meant that it is sometimes unclear in which dimension to slice up a namespace.
@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
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