Module pane_options 

Per-pane resolved view options (gutter, cursorline, sign columns, indent guides). Deliberately NOT behind the window feature: it names no gpui type, and the rule it enforces — a pane’s options come from the buffer it shows, never the active document — is worth testing in the headless build that CI runs. The view options for ONE pane, resolved against the buffer that pane shows.

GPUI’s peer of the TUI’s FrameView option fields, and the answer to the same question: a pane’s gutter, cursorline, sign columns and indent guides are properties of the buffer being painted, not of whichever buffer happens to be focused.

Why this exists as a type rather than four inline reads

It did exist as four inline reads, in the middle of the per-pane render method, and three of them resolved against active_document.option_cache — the FOCUSED buffer. So a magit view sitting beside a focused file grew line numbers its own mode turns off, and a file beside a focused magit view lost them. One of the four carried a comment admitting it (“inactive panes inherit the active value — the same pre-existing per-pane-option limitation”), and a fourth (cursorline) had a special case for preview panes only, because that was the one configuration where a pane’s buffer was known to differ from the active document. It is true of every unfocused pane.

RenderState::resolved_option_for (PI.4) is the renderer-agnostic seam built for exactly this, and its own doc names the defect it was meant to end: peers resolving options “instead of the TUI reading the live editor and GPUI reading the active document’s option_cache”. The TUI half landed; this is the other one.

Gathering them into a struct is what makes the rule checkable — the reads are now in one place with one test, instead of four places where the next option added silently picks the wrong source.

Structs

PaneOptions

Per-pane resolved view options.