Rainbow tree-sitter matches 🌈

[the-mikedavis]

Configurable, themable, nesting rainbow highlights:

This approach uses the syntax tree to guide nesting levels and highlights so it ends up being much more flexible than a naive pair-matching implementation. For example, we can highlight </> when used in Rust type parameters like struct MyStruct<'a> { .. } and not mistakenly highlight </> comparison operators. We can also capture multiple nodes, for example the #, [ and ] characters in a Rust attribute like #[cfg(windows)] and none of these characters are required to be adjacent.

The cherry on top is that we can highlight according to the syntax tree's nesting information rather than whether characters surround each other. For example, in this TOML table, characters is a sub-table of editor.whitespace and the rainbow highlights reflect that fact.

theme = "default"

[editor.whitespace]
# <- red          ^ red
render = "all"
characters = { tab = "▸", newline = "◂" }
#            ^ yellow                   ^ yellow (comes after red in base16)

It also works across injected languages like javascript injected into HTML script tags.

(You can see each of these things in action in the gif above.)

How does it work?...

This implementation leverages tree-sitter queries. We use a QueryCaptures Iterator very similar to the existing one for syntax highlights to query the parsed syntax tree for new rainbows.scm patterns.

Two new captures - @rainbow.scope and @rainbow.bracket - track nesting level and capture syntax nodes for highlighting with rainbows. Specifically: @rainbow.scope pushes a RainbowScope on a stack. When @rainbow.bracket matches, we test that the captured node is a direct descendant of the current scope. If it is, we emit highlights for it according to the scope's level of nesting.

---

Configuration...

In the theme we add a rainbow key that takes a list of Styles. You can have however many you want and you can re-use colors from the palette or even throw modifiers in there:

# ~/.config/helix/themes/my_theme.toml

rainbow = ["#fc6b59", { fg = "lavender", bg = "comet" }, "lilac", { modifiers = ["reversed"] }]

[palette]
lavender = "#a4a0e8"
comet = "#5a5977"
lilac = "#dbbfef"

A default rainbow using the red, yellow, green, blue, cyan, and magenta terminal colors is used as a fallback.

Enable the rendering of rainbow brackets in your config.toml

# ~/.config/helix/config.toml
[editor]
rainbow-brackets = true

Or enable rendering per-language in languages.toml (this overrides the config.toml setting for any languages that set this value):

# ~/.config/helix/languages.toml
[[language]]
name = "scheme"
rainbow-brackets = true

[[language]]
name = "commonlisp"
rainbow-brackets = true

When the rainbow-brackets option is disabled, rainbow brackets are not rendered or computed.

---

Status...

The current implementation is working well. Take it for a spin and let me know if you find any bugs!

[archseer]

Surprisingly little code to get this working 👍🏻

[SoraTenshi]

Would it make sense to use the color palette colors as default values if the rainbow feature is enabled?
That was my idea when i tried to work on that.

[the-mikedavis]

That could work but usually the palette has a bunch of different ui colors too, so some deeply nested brackets could end up using backgrounds / grays which may look bad. I think a default rainbow palette not based on the current theme could work ok

[archseer]

You could cheat and ignore any scopes that start_with("ui.")

[the-mikedavis]

I suspect theme colors may not be good for a theme's rainbow because they might blend in and end up looking confusing. I'll give it a try though - that would take all the guesswork out of having to come up with a default that looks good on all themes 😄

[archseer]

You could get fancy and calculate the color contrast and only pick colors that are distant enough :D

[atagen]

You could get fancy and calculate the color contrast and only pick colors that are distant enough :D

well, I have a snippet to calculate the L* luminance value (as in Lab/LCH "professional" colour systems) from an sRGB triple. I use it for exactly that, grading and excluding colours with weak contrast in a CLI app 👍

if interested Helix would be most welcome to it, I can PR it to @the-mikedavis rainbow branch?

[the-mikedavis]

Let's keep this branched focused just on the happy path for now (rainbows enabled and themed). If anything, we might want to merge this once cleaned up without any default behavior - i.e. the theme needs to have a rainbow key in order for rainbows to work - and we can find a good default palette or strategy as a follow-up.

[the-mikedavis]

The reason I lean towards a hardcoded default that uses red/orange?/yellow/green/blue/purple/etc is that it's easy to get a feel for how things are nested when you can predict the ordering of the bracket colors. If I know blue comes after green, I know where a blue tuple stands inside a huge green map or list literal.

I don't want to discourage discussion on automatically determining a good rainbow though, it sounds like there are some cool color math tricks we could use 🙂

[the-mikedavis]

I found an alternate approach for this that ends up being less complicated. Now it works similarly to the locals tracking system in the syntax highlights iterator. The queries end up being more intuitive to write and more flexible (see the updated PR description).

I think this approach is general-purpose enough: I've worked through 27 languages so far with the toughest being HTML. HTML works now so that nested XML elements behave like other nesting scopes rather than just highlighting the < and > within individual tags.

[omentic]

Hey @the-mikedavis - any chance this could be merged soon, or put back on a list of milestones? Is there anything blocking it? I keep this merged into my soft fork and it works great. It's indispensable for writing Racket/Scheme, and pretty helpful for all languages in general. And another languishing PR (#4493) is blocked on it.

I have a rebased version over at https://github.com/omentic/helix/tree/rainbow-rebase, if needed.

[JustForFun88]

I don’t understand why this PR has been pending since 2022, especially since it’s fully functional and adds valuable feature. Leaving this to plugins isn’t ideal, as it could hurt performance. VS Code faced a similar issue and ended up integrating support directly.

[x10an14]

For those asking "why not merge dis??", read #2857 (comment) and explore the different iaauea/PRs related to treesitter (that are all somewhat related to one another).

[the-mikedavis]

For some more details on top of that older comment: @pascalkuthe and I are working on new tree-sitter bindings (#10286) and the new highlighter based on those is written a way that makes running a query over injection layers very easy. (This feature uses that so that rainbow brackets are highlighted even within code fences in markdown, for example, or within JS in <script> tags in an HTML file.) The way I did that in this PR is pretty hacky - we end up duplicating code between the highlights iterator and the generic "iterator over injections" including a trait to share some similar code. The new bindings are composed better: the syntax highlight iterator is built on top of the generic query iterator. So this is blocked on #10286.

As for the feature itself: I still use this in my driver branch and have been keeping it more-or-less up to date. I'll give this PR a proper rebase so it's easier for others to use too. I'm not totally sure where other maintainers stand on the feature but I remember @archseer considering it after working on a bunch of scheme code. Even if it's something we don't pull in as a core feature I'd be interested in maintaining a plugin for it officially or personally.