tree-sitter-cpp VS tree-sitter-javascript

Grammar page (https://github.com/tree-sitter/tree-sitter-cpp) reference two documents at the very end:

- Hyperlinked C++ BNF Grammar (https://alx71hub.github.io/hcb/)

- EBNF Syntax: C++ (ISO/IEC 14882:1998(E)) https://www.externsoft.ch/download/cpp-iso.html

The second doc has a year in the title, so it's ancient af.

The feature isn't working well yet on C and C++. If I recall correctly it's based on Tree-Sitter[1] parsing, and there are still too many bugs in corresponding grammars - tree-sitter-c[2] and tree-sitter-cpp[3]. Hopefully, it will be greatly improved in the future as the share of the existing and newly written code in C and C++ is quite significant.

[1] https://tree-sitter.github.io/tree-sitter/

[2] https://github.com/tree-sitter/tree-sitter-c/issues

[3] https://github.com/tree-sitter/tree-sitter-cpp/issues

There's treesitter-cpp parser that works to some extent already. However, for complex language like c++, I think it would be better to use lsp's semantic highlighting instead

C++ is currently unsupported, but there's a good tree-sitter implementation I can add: https://github.com/tree-sitter/tree-sitter-cpp

I get the sense that treesitter is more for syntax highlighting than for real parsing, since I raised this issue[0] a while ago and I don't think anyone's really interested in it (not really interested enough myself in tree-sitter to see if it can be fundamentally solved; solving it involves making almost all production rules in the grammar parametric over two booleans).

Admittedly I haven't tested the TypeScript treesitter grammar, but I'd be surprised if the issue is fixed there. I've put together a sample file[1] that demonstrates various cases of these context dependencies. If I remember correctly, Sublime's highlighter was the best at handling these cases out of various editors I tried, though it still failed at some of the ones at the bottom involving multi-line function expressions within object literal keys. GitHub/gist uses treesitter, so you'll notice that sometimes the "REGEX" and "DIVISION" blocks are inconsistently coloured, but a correct parser should associate a colour consistently to them. Not demonstrated here, but inserting a multi-line comment in a file that is parsed incorrectly will throw the entire thing off.

[0] https://github.com/tree-sitter/tree-sitter-javascript/issues...

[1] https://gist.github.com/Maxdamantus/a11b41675fcde25ffc9b7ef0...

I believe goto_next_test requires support from the tree-sitter parser, specifically tree-sitter-javascript in the case of JS and tree-sitter-typescript in the case of TS.

Here is the tree-sitter grammar of Elisp:

https://github.com/Wilfred/tree-sitter-elisp/blob/main/gramm... (approx. 200 lines)

and here is the grammar of JavaScript:

https://github.com/tree-sitter/tree-sitter-javascript/blob/m... (approx. 1200 lines)

JavaScript evolved into a language of similar complexity as Perl 5 (the corresponding tree sitter syntax table counts almost 2000 lines, currently).

Next, clone the Javascript grammar for tree-sitter from https://github.com/tree-sitter/tree-sitter-javascript and compile it with cc -shared -fPIC -g -O2 -I src src/scanner.c src/parser.c -o ~/.emacs.d/tree-sitter/libtree-sitter-javascript.dylib.

I downloaded the tree-sitter-javascript repo, created a folder for a custom grammar package, and created a basic package.json file, but I have no clue what the Atom page is talking about regarding call_expression, and the addInjectionPoint code. ELI5?