Announcing tree-sitter-ring — a Tree-sitter grammar for the Ring programming language

[Youssef Saeed]

Hello everyone,

I'm thrilled to share the release of tree-sitter-ring — a complete Tree-sitter grammar for the Ring programming language!

Tree-sitter is the parsing technology behind modern editor features in Neovim, Helix, Zed, and Emacs. It builds a real syntax tree of your code — fast, incremental, and error-tolerant (it keeps working even while you're mid-typing). With this grammar, Ring joins that ecosystem: accurate syntax highlighting, code navigation, and a solid foundation for a new generation of Ring developer tools.

Key Features:

• Full Core Language: All three function styles, all statement terminators, classes, packages, anonymous functions, and typed parameters.
• Rich Syntax Support: String interpolation, brace-object access, all comment forms.
• Unicode Identifiers: Full support for international identifiers, including Arabic.
• Battle-Tested: 142 corpus tests; verified against Ring's own test suite (973 files) and 2,295 samples — every valid non-DSL file parses.

Use Cases:

• Modern Editor Support: Precise syntax highlighting, code folding, symbol outlines, and go-to-definition in Neovim, Helix, Zed, and Emacs.
• Developer Tools: A ready-made foundation for building a Ring formatter, linter, or language server — no need to write a parser from scratch.
• Code Intelligence: Structural search-and-replace, semantic git diffs, metrics, and documentation generators for Ring codebases.
• AI-Friendly Code: Lets AI coding assistants and code indexers understand Ring projects, so they can navigate and modify your code accurately.

Editor integrations (highlight queries, registration in nvim-treesitter/Zed/Helix) are the natural next step — and now straightforward, since the grammar is the hard part.

Getting Started:

git clone https://github.com/ysdragon/tree-sitter-ring
cd tree-sitter-ring
bun install
bun run build   # tree-sitter generate
bun run test        # run the 142 corpus tests

# Parse any Ring file:
bun run parse yourfile.ring

Learn More:

• GitHub Repository
• Tree-sitter Documentation

Known Limitations:

Syntax that Ring defines at runtime can't be captured by any static grammar — this affects the NaturalLib natural-language DSL (I want window, ...) and keywords/operators remapped via ChangeRingKeyword/ChangeRingOperator. Also, the keywords Ring demotes only via runtime counters (ok/on/off/catch/done/again/but/else/other/case when used as plain names outside their construct) always stay keywords here — a static parser can't see runtime state. Everything in the core language is fully supported.

Contributions are welcome!

Have ideas or found a bug? Please open an issue or submit a pull request on GitHub.

Your feedback is greatly appreciated!

Hope you find tree-sitter-ring useful!

Best regards,
Youssef

[Mahmoud Fayed]

Hello Youssef

Thank you very much, this is very useful for many tools :D

Keep up the GREAT WORK :D

Greetings,

Mahmoud  

[Youssef Saeed]

Hello Mahmoud,

Thank you so much for your kind words!

Best regards,

Youssef

[Mansour Ayouni]

Hello Youssef,

Very useful !

I appreciate the direction you took to cover Ring development tooling around modern norms and practices.

This is critical to Ring adoption.

Looking forward to testing your tree-sitter and considering including it to my projects.

All the best,

Mansoiur

--

---
You received this message because you are subscribed to the Google Groups "The Ring Programming Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ring-lang+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ring-lang/5ec10747-9614-41fb-b2fa-086ae035557dn%40googlegroups.com.

[Youssef Saeed]

Hello Mansour,

Thanks a lot for the support! Looking forward to your feedback once you test it out.

Best regards,

Youssef

[Gaiamap]

Hi Youssef,

Congratulations: tree-sitter-ring is an impressive piece of work, and the kind that widens what is possible around a language rather than just adding to it.

I spent some time inside the grammar rather than only reading the announcement, and what convinced me is a small thing: the identifier class defined by exclusion. It matches Ring's own scanner character for character (the sort of detail you only get right by reading the sources). The same care shows in using an external scanner for the same-line rules, and in putting your own corpus tests next to the real test suite and a few thousand samples.

I have been poking at Ring from a different angle for a while, and that has meant checking a good many of the language's finer points against the interpreter. Two of them touch your grammar, so let me put them on the table plainly.

1) The same-line rule for postfix. In Ring the end of a line does not always close an expression: after the closing parenthesis of a call, or the closing bracket of an index, the parser keeps looking for a further index or call on the lines that follow, and neither a semicolon nor a blank line stops it, since for the scanner they are the same token. After an identifier, a string, a number or a ++ it does stop; and the bracket that closes a list literal does not arm it either, which is why general/test110 in the suite parses the way it does. So the restriction you enforce holds in most positions and is a little too strict after those two closers. Nothing in the suite depends on the difference. It would begin to matter for the formatter and the structural search-and-replace you list among the use cases, where the tree decides what gets rewritten.

2) The counter-guarded keywords. I suspect that limitation may be removable. Ring blocks the demotion of ok, but, on, case, off, catch, done, again, else and other using the parser's own nesting counters (compile-time state, the same kind your external scanner already keeps for parentheses) rather than anything from the running program. The rule, as far as I have been able to check it, is that one of those words stays a keyword for the whole extent of the construct that uses it, its condition included, and it stays one inside nested constructs of other kinds; else and other need both the if and the switch nesting to be closed. There is one fixed exception: in load again "file.ring" the word again is always part of the command.

Best wishes for the editor integrations: that is where most people will feel the difference.

Cesare G. Fanelli
(the G could be Y :D )

[Youssef Saeed]

Hello Cesare,

Thank you so much for taking the time to dive deep into the code and grammar! It means a lot to receive such a detailed, thoughtful, and high-quality review from someone who understands the inner workings of the Ring scanner and Compiler/VM so well.

Your points are extremely insightful:

1. Postfix Same-Line Rules: You're completely right. While the current restriction passes the existing test suite, accurate handling of continuations after closing parentheses and brackets across lines is crucial for formatters and structural search-and-replace tools. I'll be revisiting this rule to ensure the AST reflects those chained calls and indices correctly.

2. Counter-Guarded Keywords: This is a fantastic insight! I had previously assumed these demotions relied on runtime state, but your explanation of the parser's compile-time nesting counters makes total sense. Since Tree-sitter's external scanner can maintain state (similar to parenthesis depth tracking), this might actually be solvable statically. I'm definitely going to experiment with tracking construct depth in the external scanner to see if we can lift this limitation.

Thanks again for your kind words, encouraging feedback, and for sharing your deep knowledge of Ring's edge cases. Feedback like this makes building language tooling so much more rewarding!

Best regards,
Youssef

[Gaiamap]

Hi Youssef,

Glad it was useful, and good luck with the work.

It is a pleasure to read the announcements of your projects: they are very interesting and useful, and I am already curious about the next one.

Best regards,

Cesare