[idea] Show pane borders in single-pane tabs

[h14h]

idea / problem

Herdr draws pane borders when a tab contains multiple panes, but the border disappears when the tab contains only one pane. I like the visual framing used for split layouts and would like the option for that framing to remain consistent when moving between single-pane and multi-pane tabs. In Herdr 0.7.5, ui.pane_borders = true does not draw a border for an ordinary single-pane tab.

requested change

Add an option to keep pane borders visible when a tab contains only one pane. For example:

[ui]
pane_borders = true
single_pane_borders = true

Alternatively, pane_borders could support modes such as "splits" and "always", while preserving the current behavior by default. Ideally this would use the same border styling, colors, and pane-label behavior as multi-pane layouts.

why you want this

An always-visible border would make tabs and layouts feel visually consistent. It would preserve the framing and focused-pane appearance I like in split layouts even when I only need one pane, avoiding a noticeable visual change whenever a split is opened or closed.

[Keltirion]

I would also like this feature, I run couple of editors on single-pane that would like to be visually separated from sidebar/tabs

[alexandersix]

I was just thinking the same thing and came here to see if anyone else agreed.

For me, there's just the smallest bit of visual context shifting that occurs when going from a single pane (no border) to multiple panes (with borders) that throws me off.

Obviously, this is just a "for polish" sort of change, but I'd like to see it!

Happy to give opening a PR a stab as well if that would be helpful, assuming I'd be allowed to contribute. Even if it's just an opened PR to explore whether adding this is worthwhile, I can make the effort there if needed 👍🏻

[lunetics]

Where this lives on current master (0.8.0, 1f1e434): the single-pane case is hard-gated in the renderer, so ui.pane_borders = true can't reach it. src/ui/panes.rs:112-113 sets info.borders = if !multi_pane || !pane_borders { Borders::NONE }, and the same multi_pane condition guards the two other border paths at :182 and :237. A config option would just need to feed those three gates; the border drawing, styling and resize mechanics it would enable all exist already for the multi-pane case.

One argument for why this is more than visual consistency: border labels hang off the border. render_pane_border_titles skips any pane without Borders::TOP (src/ui/panes.rs:623), so on a single-pane tab you also lose the agent label (ui.show_agent_labels_on_pane_borders) and any title reported via pane report-metadata --title. We run auto-generated task titles on pane borders across many workspaces, and they silently disappear exactly on the tabs that hold one long-running agent, which are the ones where a glanceable title helps most.

[patrickfeeney03]

I would like the consistency too. Specially related to naming the pane and actually seeing its name, since currently you can't see it if a a tab has a single pane.

[prakharw]

+1 from a plugin-workaround angle. I tried faking this with a plugin that splits off a companion pane whenever a tab drops to one real pane, so pane_borders has something to draw against.

my observations:

1. Plugins can't do this properly — there's no rendering hook, only spawning real panes.
2. Even that hack is capped: herdr pane split --ratio clamps to a 90/10 max split no matter what ratio you ask for, so the companion pane still eats a real ~10% of width. No way to get thinner via the plugin/pane API.

I agree with what @lunetics found in src/ui/panes.rs — this needs the multi_pane gate to grow a config-driven "always" mode, not something userland can patch around.