#1938·rio

[colors] split-active is parsed but never used -- discarded as _border_active_color in ContextGrid::new

Author: shaunwenCreated Sep 15, 2026Updated Sep 15, 2026

Summary

[colors] split-active is parsed, defaulted, and threaded all the way to ContextGrid::new -- where the parameter is underscore-prefixed and discarded. Setting it has no effect: every split divider paints with [colors] split, focused or not.

Tested on 0.5.27, macOS 26 (Darwin 25.6.0).

Repro

toml
[panel]
border-width = 8

[colors]
split = "#ff0000"
split-active = "#00ff00"

Open a new window, Cmd+D. Both dividers are red; nothing is ever green, regardless of which pane has focus.

Where it goes missing

The value is plumbed correctly right up to the end:

  • rio-vt/src/config/colors/mod.rs:265-270 -- split_active, rename = "split-active", default #44C9F0
  • frontends/rioterm/src/context/mod.rs:1087 -- split_active_color: config.colors.split_active
  • frontends/rioterm/src/context/mod.rs:421 -- passed into ContextGrid::new

Then:

  • frontends/rioterm/src/layout/mod.rs:161 -- the parameter is _border_active_color and is never read
  • frontends/rioterm/src/layout/mod.rs:94-97 -- BorderConfig has only width and color, no active variant
  • frontends/rioterm/src/layout/mod.rs:424-453 -- get_panel_borders paints every separator with the single self.border_config.color

walk_separators already hands the visitor child_a/child_b, and self.current identifies the focused node, so the information needed to pick the active color is available at the call site.

Note on prior art

I see #989 ("Split: Allow to configure border colors for the active") was closed in favour of unfocused-split-opacity, with the reasoning that an active border colour would be redundant. That's a reasonable call -- this report isn't asking to relitigate it.

The issue is that the config key shipped anyway. split-active currently looks like a working setting: it parses, it has a default, it appears in serialised config, and it fails silently. Whichever way the design question goes, the surface and the behaviour should agree -- either wire it up in get_panel_borders, or drop the field and the unused parameter so it can't be set.

Happy to send a PR for either.