Skip to content

text: Keep a line with inline code as tall as a plain line - #3240

Merged
huacnlee merged 1 commit into
mainfrom
fix/inline-code-line-height
Sep 25, 2026
Merged

huacnlee merged 1 commit into
mainfrom
fix/inline-code-line-height

Conversation

@huacnlee

Copy link
Copy Markdown
Member

Fixes #3162

Description

In a Markdown TextView, a line containing inline code was taller than a plain line, so a tight list with one code item was unevenly spaced (the code item looked pushed down). A line with inline code is laid out by InlineFlow, a plain line by GPUI's text layout, and they disagreed on the line height in two ways:

  • Per-run leading. Every text run was centered in its own line-height box and that box was merged into the line. The inline-code run (mono font at 0.875) has different ascent/descent proportions from the body font, so the merged line grew, on one side only. The body strut was also stretched to the font's ascent + descent when that exceeds the line height, which a plain line never does.
  • Rounding. The flow took its line height from Window::line_height, which rounds to a whole logical pixel before snapping to device pixels. StyledText does not round first, so at fractional scale factors (e.g. 1.6: 25.888 → 26 → 26.25 instead of 25.625) the flow line was one device pixel taller.

Changes in crates/base/src/text/inline_flow.rs:

  • Resolve the flow's line height exactly as StyledText does.
  • Keep the body line box at the line height; text runs join the line by their glyph box and may overflow it as far as body glyphs do.
  • When positioning, give each text run's box equal leading on both sides as far as the line allows, so its glyphs stay on the line's baseline and a body run gets exactly the line box. The code background moves with it.

Measured in the real app at scale 1.6 with the issue's list (plus a CJK list), gaps between bullets in device pixels:

gaps
Before 41, 43, 41, 41, 44
After 41, 41, 41, 41, 41

No public API changes.

How to Test

  • cargo test -p gpui-base --lib; new regressions inline_code_line_is_as_tall_as_a_plain_line (scale 1.6/2, zoom 1/1.25) and inline_code_line_is_as_tall_as_a_plain_line_when_glyphs_overflow_it fail before this change.
  • Render - plain item one\n- item with \inline code`\n- plain item three` on a fractional-scale display; the items are evenly spaced.

🤖 Generated with Claude Code

A line containing inline code is laid out by `InlineFlow`, a plain line by
GPUI's own text layout, and the two disagreed on the line height:

- Every text run added its own centered leading to the line, so a run whose
  ascent/descent proportions differ from the body font's (the smaller mono
  inline code) made the line taller, on one side only. The body strut was
  also stretched to the font's ascent + descent when that exceeds the line
  height, which a plain line never does.
- The line height came from `Window::line_height`, which rounds to a whole
  logical pixel before snapping to device pixels; `StyledText` does not, so
  at fractional scale factors the flow line was a device pixel taller.

Runs now join the line by their glyph box, may overflow it as far as body
glyphs do, and get their leading back symmetrically when positioned; the
line height is resolved as `StyledText` resolves it.

Fixes #3162

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@huacnlee
huacnlee merged commit 8e6e9cf into main Sep 25, 2026
12 checks passed
@huacnlee
huacnlee deleted the fix/inline-code-line-height branch September 25, 2026 15:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

TextView (markdown): the line containing inline code gets extra height above the baseline — uneven spacing in tight lists

1 participant