tree-sitter: parser generator tool and an incremental parsing library
Mike Brown
mikey.be at gmail.com
Sat Feb 27 11:12:03 UTC 2021
On Friday, 26 February 2021 at 20:06:46 UTC, Jacob Carlborg wrote:
> On 2021-02-22 16:56, James Blachly wrote:
>> https://tree-sitter.github.io/tree-sitter/
>> https://github.com/tree-sitter/tree-sitter
>> https://news.ycombinator.com/item?id=26225298 (currently #1 on
>> HN)
>>
>> Will be keeping an eye on this. If it gains traction*, it
>> would be nice (and possibly important) to have a Dlang parser.
>> Haven't looked in depth at the grammar yet -- appears to be
>> context free grammar.
>>
>> *Supposedly Neovim will be using this going forward
>
> I wonder how the text editor/IDE integration is supposed to
> work. To build the parser you need Node.js and a C compiler. Is
> the author of the grammar supposed to pre-compile everything
> and it's loaded as a dynamic library? That would defiantly make
> it less flexible that the current approach TextMate grammars.
> TextMate grammars are very easy to modify on the fly and the
> editor will immediately be able to use the new grammar. No
> building, no compilation and no loading of dynamic libraries.
> But I do know how limiting TextMate grammars are.
>
> I guess in theory the editor could ship with Node.js and a C
> compiler and compile on the fly to have the same flexibility as
> TextMate grammars.
>
> BTW, I'm wondering if it needs to be Node.js or if any
> JavaScript engine would work. At least macOS already ships with
> a JavaScript engine.
tree-sitter is written in C, and all parsers are written in C.
Atom is the primary editor using tree-sitter, that uses Node.js
(/Electron).
I also forgot to mention the other major benefit/goal to
tree-sitter. It is an incremental parser, so the parse tree is
updated at every keystoke. (this is mentioned in this threads
title).
Is this discussion for parsing in general, or for the D
frontend/IDEs?
More information about the Digitalmars-d
mailing list