Yeah it kinda does all three. We think Tree-sitter could adopt CSTML as a way of communicating its parse results with relative ease.
We also think that at some point in the future we could run Tree-sitter grammars without first compiling them from JS to C or wasm.
Our major innovations over Tree-sitter are scripted grammars (no compile step), streaming parsing, and the idea that we are a standalone complete source of truth for an IDE, where Tree-sitter only wants to be half the story: it expects to sync with a text buffer where the text buffer is the source of truth.
> the idea that we are a standalone complete source of truth for an IDE
So that XML-like tree would become the source of truth?
> where Tree-sitter only wants to be half the story: it expects to sync with a text buffer where the text buffer is the source of truth.
There are probably a ton of reasons for this, e.g. 1) The source of truth at the file system level is actually the bare text. 2) Performance reasons. 3) Stuff like git diff is easier to implement.
Yep, the XML-like tree would become the source of truth.
Because we're designing a new and radically simpler IDE we'll just skip the part where the source of truth is bare text on disk (i.e. the git working tree).
We still will be able to read and write flat text files from disc if the user needs to, but our reason for being is to see what kind of good things we could make happen if cut out the middleman and make the IDE's state/history (i.e. undos) and the VCS state/history one and the same. To that end our in-memory representation of the CSTML trees is a reference-immutable btree with efficient copy-writes through deep structural reuse.
Yeah it kinda does all three. We think Tree-sitter could adopt CSTML as a way of communicating its parse results with relative ease.
We also think that at some point in the future we could run Tree-sitter grammars without first compiling them from JS to C or wasm.
Our major innovations over Tree-sitter are scripted grammars (no compile step), streaming parsing, and the idea that we are a standalone complete source of truth for an IDE, where Tree-sitter only wants to be half the story: it expects to sync with a text buffer where the text buffer is the source of truth.
> the idea that we are a standalone complete source of truth for an IDE
So that XML-like tree would become the source of truth?
> where Tree-sitter only wants to be half the story: it expects to sync with a text buffer where the text buffer is the source of truth.
There are probably a ton of reasons for this, e.g. 1) The source of truth at the file system level is actually the bare text. 2) Performance reasons. 3) Stuff like git diff is easier to implement.
Yep, the XML-like tree would become the source of truth.
Because we're designing a new and radically simpler IDE we'll just skip the part where the source of truth is bare text on disk (i.e. the git working tree).
We still will be able to read and write flat text files from disc if the user needs to, but our reason for being is to see what kind of good things we could make happen if cut out the middleman and make the IDE's state/history (i.e. undos) and the VCS state/history one and the same. To that end our in-memory representation of the CSTML trees is a reference-immutable btree with efficient copy-writes through deep structural reuse.
5 replies →