Do you have an equivalent of TreeCursors or tree-sitter-generate?

There are at least some use cases where neither queries nor walks are suitable. And I have run into cases where being able to regenerate and compile grammars on the fly is immeasurably helpful.

At least for my use cases, this would be unusable.

Also, what the hell is this:

> partial [..] missing external scanner

Why do you have a parsing mode that guarantees incorrect outputs on some grammars (html comes to mind) and then use it as your “90x faster” benchmark figure?

▲

odvcencio an hour ago | parent [-]

the 90x figure is on Go source for apples to apples against CGO bound tree-sitter.

your use case is not one i designed for although yeah maybe the readme has some sections too close. the only external scanner missing atm is norg. now that i know your use case i can probably think of a way to close it

	▲	trickypr an hour ago \| parent [-]
		So your benchmarks are primarily just “how fast is go’s c interop” rather than any algorithmic improvement on tree-sitter? Edit: yep, you are just calling a c function in a loop. So your no-op benchmark is just the time it takes for cgo to function. I would not be able to get any perf benefits from e.g. rust