Let layout determine the editor's remaining height

[Michael Greene (mgreenegit)]

Problem

draw_editor currently determines the text area's height by subtracting fixed UI reservations from the viewport: 2 rows with search hidden/disabled, 4 with Search, and 5 with Replace. The adjacent TODO identifies the underlying limitation:

The layout code should be able to just figure out the height on its own.

This duplicates information that is already present in the UI tree. The editor must know how much space its siblings consume, and that accounting must stay synchronized with what is actually drawn.

It also allows a negative intrinsic height in short viewports: a three-row viewport with Replace active requests 3 - 5 = -2. The intrinsic-size setter stores that value, and the layout engine uses it in parent sizing and sibling positioning.

Change

Add one opt-in layout attribute, Context::attr_fill_height, and use it for the editor's text area (or its empty placeholder when no document is open).

The existing vertical-block layout now:

1. Reserves the measured outer heights of fixed siblings and the padding/borders of filling children.
2. Clamps the remaining content-height budget to zero.
3. Divides that budget between children marked to fill, assigning any indivisible remainder to later filling siblings.

The editor is the only production caller added here. With one filling child, its content height is simply:

max(parent content height - fixed sibling heights - filling-child decorations, 0)

Menu, search and status rows are accounted for from the current tree, including siblings drawn after the editor. Floating nodes are outside that stack and do not consume its height.

This removes the editor's hard-coded row subtraction and resolves the adjacent TODO. It also preserves the small-viewport safety goal: insufficient space gives the unbordered editor zero height, not a negative requested size.

Why this is useful

• One source of layout information: changing the surrounding UI's height no longer requires updating a second reservation table in draw_editor.
• The usual geometry stays the same: when the existing menu/search/status rows fit, the editor occupies the same remaining rows and the status bar follows it at the bottom.
• The safety check belongs to allocation: the nonnegative budget is enforced where the available space is distributed, rather than in a caller that reconstructs the layout.

This is a focused vertical-height capability, not a general flexbox system: no weights, shrink priorities, new layout modes or horizontal sizing changes. Unmarked children keep their existing intrinsic-height allocation. Intrinsic measurement and the specialized table/scrollarea layout rules are unchanged.

Scope and review

Three files: the editor call site, the TUI attribute/allocation implementation, and focused TUI tests. No dependencies, settings, commands or platform-specific code are added.

This revision supersedes the PR's initial caller-side clamp and arithmetic-only test with the layout-based fix and geometry tests. It deliberately expands the original one-file scope to address the existing TODO; the original commit remains in the history.

It does not guarantee that all controls remain visible or usable in arbitrarily short terminals, and it does not change existing clipping or overflow policy.

Validation

Four regressions inspect actual node rectangles after the TUI layout pass:

• Editor-shaped stacks for hidden/disabled search, Search and Replace, plus different header/search/footer heights to verify that the allocator does not depend on the editor's constants.
• No document, an empty text buffer, and a long text buffer, with shrinking/growing Resize events through heights 1-8, ordinary heights 24/80, and the largest accepted terminal height, 32767.
• Separate direct-layout checks at zero and COORD_TYPE_SAFE_MAX; those geometry bounds are outside the terminal Resize event contract.
• Floating-node exclusion, unchanged fixed-only layout, two filling siblings sharing an odd-sized budget, and nested padding/borders with a trailing status row.

Before the allocator change, the initial three layout regressions failed. For example, an eight-row viewport left the empty editor at zero rows instead of the expected six; the nested case also displaced the trailing status row. All four final regressions pass.

Local verification on Windows with Rust 1.97.1:

cargo test --offline --locked --package edit --lib --bin edit
# library: 47 passed, 0 failed, 1 existing ignored
# binary:   2 passed, 0 failed

cargo clippy --offline --locked --package edit --lib --bin edit --tests -- --no-deps --deny warnings
# passed

These exercise the real layout engine and text-area widgets, but are not end-to-end tests of the running editor or evidence of a reproduced crash. Cross-platform validation remains for upstream CI; the local results are not a claim that CI has passed.

Origin

The boundary case arose during a separate console experiment, but this change applies independently to the existing editor. No console implementation, providers or AI code is included, and acceptance does not require agreement on those features.

[Leonard Hecker (lhecker)]

I don't believe this is the right direction. My intention was to implement CSS grid & flexbox support in the near term (or at least a subset of those). Like this: https://jsfiddle.net/vkubqc4d/