nandi/jolt-native · 5ba95e0

⑂ 5ba95e0

Let a node say how tall it is willing to be

`:height-request` was a floor on both of a node's numbers and there was
nothing on the other end, so a `:scroll` was as tall as the list inside it.
That makes a viewport a viewport only on a screen too short to draw its
content in full — on any other it quietly takes the rows its neighbours were
sharing and shows everything, which is the one thing it was put there not to
do.

`:max-height` is that ceiling, on the natural size alone: what a node is
asking for, not what it can be squeezed to. A picture already read the prop
for its own rows and comes out under the cap either way, so this is the same
answer it was giving.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

nandi committed 2026-09-12T00:10:06-07:00 Browse files

5ba95e0 parent: e39a374

modified crates/jolt-tui/src/layout.rs +13 -2 Viewed

@@ -7,6 +7,13 @@
7	7	//! `:height-request` are a floor on both numbers, so asking for four rows gets
8	8	//! four rows even when space is short.
9	9	//!
	10	+//! `:max-height` is the ceiling on the other end, and only a natural one: a
	11	+//! node that says it is four rows tall is asking for at most four, however
	12	+//! much is in it. It is there for a `:scroll`, whose content is as long as the
	13	+//! list and whose whole job is to be shorter than that — without it a viewport
	14	+//! is a viewport only on a screen too short to draw it in full, and on any
	15	+//! other it takes the rows its neighbours were sharing.
	16	+//!
10	17	//! Nothing here touches a terminal or the screen grid: sizes are arithmetic on
11	18	//! the tree, which is why the layout tests below need no TTY.
12	19
@@ -423,9 +430,13 @@ fn height_for_width_uncached(tree: &Tree, id: u32, avail: u16) -> u16 {
423	430	}
424	431	}
425	432	};
426		- content
	433	+ let want = content
427	434	.saturating_add(pad.saturating_mul(2))
428		- .max(props.cells("height-request", 0))
	435	+ .max(props.cells("height-request", 0));
	436	+ match props.cells("max-height", 0) {
	437	+ 0 => want,
	438	+ most => want.min(most),
	439	+ }
429	440	}
430	441
431	442	/// The least `id` can be squeezed to at `avail` columns wide.

  //! `:height-request` are a floor on both numbers, so asking for four rows gets
  //! four rows even when space is short.
  //!
++//! `:max-height` is the ceiling on the other end, and only a natural one: a
++//! node that says it is four rows tall is asking for at most four, however
++//! much is in it. It is there for a `:scroll`, whose content is as long as the
++//! list and whose whole job is to be shorter than that — without it a viewport
++//! is a viewport only on a screen too short to draw it in full, and on any
++//! other it takes the rows its neighbours were sharing.
++//!
  //! Nothing here touches a terminal or the screen grid: sizes are arithmetic on
  //! the tree, which is why the layout tests below need no TTY.
              }
          }
      };
--    content
++    let want = content
          .saturating_add(pad.saturating_mul(2))
--        .max(props.cells("height-request", 0))
++        .max(props.cells("height-request", 0));
++    match props.cells("max-height", 0) {
++        0 => want,
++        most => want.min(most),
++    }
  }
  /// The least `id` can be squeezed to at `avail` columns wide.