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
[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 #44C9F0frontends/rioterm/src/context/mod.rs:1087 -- split_active_color: config.colors.split_activefrontends/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 readfrontends/rioterm/src/layout/mod.rs:94-97 -- BorderConfig has only width and color, no active variantfrontends/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.
Summary
[colors] split-activeis parsed, defaulted, and threaded all the way toContextGrid::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
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#44C9F0frontends/rioterm/src/context/mod.rs:1087--split_active_color: config.colors.split_activefrontends/rioterm/src/context/mod.rs:421-- passed intoContextGrid::newThen:
frontends/rioterm/src/layout/mod.rs:161-- the parameter is_border_active_colorand is never readfrontends/rioterm/src/layout/mod.rs:94-97--BorderConfighas onlywidthandcolor, no active variantfrontends/rioterm/src/layout/mod.rs:424-453--get_panel_borderspaints every separator with the singleself.border_config.colorwalk_separatorsalready hands the visitorchild_a/child_b, andself.currentidentifies 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-activecurrently 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 inget_panel_borders, or drop the field and the unused parameter so it can't be set.Happy to send a PR for either.