charmbracelet / bubbles / 32939514982

59%

main: 58%

Pull #1030

github

feat(textarea): add an optional line highlighter

There is no way to style parts of a line in a textarea. Apps that want
token highlighting in their prompt — @file mentions, /command names,
anything lexical — have to either post-process the rendered string
(fighting ANSI escapes the textarea just emitted) or fork the render
loop wholesale.

Add a LineHighlighter hook:

    type LineHighlighter interface {
        Highlight(lineIdx int, line []rune) []lipgloss.Range
    }

    func (m *Model) SetHighlighter(h LineHighlighter)

The hook is consulted once per logical line per render and returns style
ranges over that line's runes. The renderer intersects those ranges with
each wrapped segment, so implementations never think about wrapping and
never see a segment boundary.

Keeping the interface range-based, rather than a func(string) string
that rewrites ANSI, means implementations never parse or preserve escape
sequences, and the textarea's wrap and cursor math keeps operating on
raw runes.

Neither the cell under the virtual cursor nor a selected segment is
styled by ranges. The renderer already splits cursor-line content into
pre- and post-cursor segments, and an active selection short-circuits
the segment entirely, so no two span-styling features can fight over the
same cell.

With no highlighter installed the render path is byte-identical to
before — styleSegment short-circuits to the plain render when there are
no ranges.

Two subtleties worth stating, because both are easy to get wrong:

Rune offsets are converted to display cells with ansi.StringWidth rather
than by summing per-rune widths. lipgloss.StyleRanges resolves the cell
offsets it is handed via ansi.Cut, which segments by grapheme cluster.
Per-rune summing disagrees on every cluster built from more than one
rune — an emoji with a skin-tone modifier scores 4 instead of 2, a ZWJ
family 7 instead of 2 — and the highlight then lands that many cells
right of its token.

StyleRanges also walks... (continued)

67 of 67 new or added lines in 2 files covered. (100.0%)

3577 of 6114 relevant lines covered (58.51%)

207.02 hits per line