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.

[the-mikedavis]

This branch gets a lot of conflicts but they're usually trivial: changes to the autogenerated lang-support.md file cause conflicts when new languages are merged. I'll push up the latest rebase though - it looks like there have been a bunch of smaller changes that caused true conflicts since I last pushed.

#5176 operates on trees while this branch covers queries. We'll need both to be able to work across injection layers for all tree-sitter features but their implementations are separate. It's basically tree_sitter::TreeCursor (5176) vs tree_sitter::QueryCaptures (this branch).

I've been looking at the mechanism for running queries across injections again as a part of a new tree-sitter-based feature and I found some changes that will make it easier to use this for other tree-sitter features and remove any performance penalties when the feature is turned off, so I will set this as a draft for now. I think it will be better to land the query changes as part of a smaller feature or a feature already in-tree so I'm planning on looking at textobjects after the next release before revisiting this.