ADR-0033: Two side-by-side editor groups

• Status: Accepted
• Date: 2026-07-06
• Deciders: jka
• Decision: D33

Context

Users wanted two ordinary editable tabs next to each other, not the read-only compare overlay of ADR-0028. The GUI was written around a single editor: one text widget, one active buffer, one highlight cache, each a global.

Decision

The split is a frontend feature; the core does not change. The core already holds any number of buffers by id and has no opinion on how many are displayed (ADR-0022).

• The single-editor globals are replaced by an editor group record (widget, tab order, active buffer, highlight cache). The GUI holds at most two groups and a focused group. Editor procedures take a group and default to the focused one. Existing behaviour was preserved first with one group, then the second group was enabled.
• Each group has its own tab strip, so a tab's group is where it is shown. A buffer belongs to exactly one group at a time.
• Actions: Split Editor, Move to Other Group, Unsplit. A group that becomes empty collapses into the other. A tab's context menu holds only actions about that tab (move, copy path, close); "Close Other Tabs" was rejected because it acts on other tabs.
• Tabs can be dragged between groups and reordered within a group with plain Tk press, motion and release bindings; no drag-and-drop extension is used. The first split centres the sash; later moves never override a width the user set.

The first version supports exactly two groups and does not persist the split across restarts.

Consequences

• A long-reserved capability landed with the core untouched.
• The single-editor assumption became a small explicit abstraction, which later features (find bar, modes, gutter, context menu) act on through the focused group.
• Showing the same buffer in both groups is deferred; it needs per-group view state.
• Merging the compare view into editor groups remains a possible later simplification.