feat(api): wrap inline highlight chips across lines#226
Merged
Conversation
…scing) A multi-word highlight chip now tokenizes into words tagged with a shared group; the words wrap with the surrounding line via the normal fit loop, and toInlineParagraphLine coalesces the same-group tokens on each visual line into one ParagraphTextSpan — so a wrapped chip paints one continuous rounded fill per line-fragment, not a box per word. Horizontal padding sits on the run's outer edges (lead on the first word, trail on the last), so a continuation fragment is open on the inner break; the soft-wrap space at a break is collapsed so the fill ends at the last visible glyph. A single over-wide chip word stays atomic on its own line; non-chip text rendering is unchanged. Tests: a multi-word chip wraps to one coalesced fill per fragment (slice padding); the wrapped fill spans an extra line vs a single-line chip; a wrapped chip keeps its full text across the break with plain text on both sides; two adjacent distinct chips stay separate; a wrapped linked chip is clickable per fragment. The example gains a wrapping section; CHANGELOG updated.
A wrapped highlight chip whose break lands so the inter-word space leads the continuation line kept that space (chip tokens are exempt from the leading trimmer) — the mirror of the already-collapsed trailing case — so the continuation fill started a space-width left of the first glyph. Make the seam-space collapse symmetric: drop a leading inter-word space (leadPad == 0) as well as a trailing one. Adds a width-sweep test asserting no chip fragment leads or trails with a soft-wrap space, and locks the final fragment's closed-right pad.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Inline highlight chips (the GitHub inline
codelook + status badges) shipped in#225 as a single atomic fragment — a multi-word chip stayed on one line and a chip
wider than the column overflowed. This adds wrapping: a chip flows and breaks with
the surrounding line, like a browser highlight.
What changed
(
InlineHighlightRunidentity); the words wrap via the normal greedy fit loop.TextFlowSupport.toInlineParagraphLinecoalesces the same-group tokens on eachvisual line into one
ParagraphTextSpan, so a wrapped chip paints one continuousrounded fill per line-fragment — not a box per word.
the last), so a continuation fragment is open on its inner break edge (slice). The
soft-wrap space at a break is collapsed on BOTH edges, so the fill hugs the visible
glyphs and the seam space stays out of line width (no alignment drift).
is unchanged — the
for→whilespan-emission rewrite is byte-identical for plain/ image / shape / SVG spans.
Verification
./mvnw test -pl .→ BUILD SUCCESS, full suite green. NewInlineHighlightRenderTestcoverage:
InlineHighlightExamplegains a wrapping section, regenerated and visually verified.Lane: shared-engine (layout) + canonical DSL. CHANGELOG updated.
Follow-up to #225 (inline highlight chips, already merged). Deferred cosmetics: the
chip band is sized to the line's text height rather than the chip's own font, and a
single over-wide chip word can still overflow on center/right alignment — both minor,
not addressed here.