input: Add collection-owned geometric range decorations

[feigeCode]

Description

Editors need geometric highlights for review ranges, search hits, and similar annotations that text styling cannot express. This PR adds collection-owned, edit-tracked range decorations with Fill and Frame styles. Independent owners can update their own collections without replacing another owner's decorations. The renderer clips ranges to visible shaped lines, including soft wraps, CRLF, and folds, and queries an interval index for visible spans.

The Editor story and English/Chinese documentation show the API and its ownership and edit behavior. Gutter markers and inline widgets are outside this PR.

Screenshot

Current Editor decoration rendering:

Public API

gpui-base (gpui_base::input)

• pub enum RangeDecorationStyle { Fill, Frame } — selects a continuous fill or one-pixel frame; the enum is #[non_exhaustive].
• pub struct RangeDecoration — stores a geometric decoration over a half-open UTF-8 byte range.
• RangeDecoration::new(range: Range<usize>) -> Self — creates a frame with the editor foreground color.
• RangeDecoration::range(&self) -> &Range<usize> — reads the supplied byte range.
• RangeDecoration::style(&self) -> RangeDecorationStyle — reads the paint style.
• RangeDecoration::color(&self) -> Option<Hsla> — reads the optional color override.
• RangeDecoration::with_style(self, style: RangeDecorationStyle) -> Self — chooses fill or frame.
• RangeDecoration::with_color(self, color: Hsla) -> Self — overrides the default color.
• pub struct RangeDecorationCollection — handle for one independently owned set of ranges.
• RangeDecorationCollection::set(&self, decorations: Vec<RangeDecoration>, cx: &mut App) — replaces this collection's entries.
• RangeDecorationCollection::append(&self, decorations: Vec<RangeDecoration>, cx: &mut App) — appends entries in paint order.
• RangeDecorationCollection::clear(&self, cx: &mut App) — empties the collection while keeping it reusable.
• RangeDecorationCollection::dispose(&self, cx: &mut App) — releases the collection and invalidates its handles.
• RangeDecorationCollection::get_ranges(&self, cx: &App) -> Vec<Range<usize>> — reads the tracked byte ranges.
• EditorState::create_range_decorations_collection(&mut self, decorations: Vec<RangeDecoration>, cx: &mut Context<Self>) -> RangeDecorationCollection — creates an independent collection.
• InputExtras::range_decorations(&self, ranges: &[Range<usize>]) -> Vec<&RangeDecoration> — supplies decorations intersecting visible, non-folded spans; its default implementation returns an empty vector.

gpui-component (gpui_component::input)

• pub use gpui_base::input::{RangeDecoration, RangeDecorationCollection, RangeDecorationStyle}; — exposes the same types through the styled input API. EditorState and its new method are also available through this re-export.

Breaking Changes

InputExtras gains a defaulted method. Existing implementations compile unchanged; custom implementations can override it to supply geometric decorations.

 impl InputExtras for MyExtras {
+    fn range_decorations(&self, ranges: &[Range<usize>]) -> Vec<&RangeDecoration> {
+        // Return decorations intersecting the visible ranges.
+        Vec::new()
+    }
 }

How to Test

• cargo test -p gpui-base --locked
• cargo test -p gpui-component input:: --locked
• cargo test -p gpui-kit --features test-support --test input --locked
• cargo check -p gpui-component-story --locked
• cargo clippy -p gpui-base --all-targets --locked -- -D warnings
• cargo fmt --all -- --check

The range decoration tests cover edit tracking, collection lifetime, viewport clipping, wrapping, CRLF, folds, and interval-index results with 100,001 decorations. The current PR CI checks pass on macOS, Linux, and Windows. Desktop story interaction has not been manually checked.

Checklist

• I have read the CONTRIBUTING document and followed the guidelines.
• Reviewed the changes in this PR and confirmed AI generated code (if any) is accurate.
• Passed cargo run for story tests related to the changes.
• Tested macOS, Windows and Linux platforms performance (if the change is platform-specific): not applicable; this change is not platform-specific.

[huacnlee]

Thanks for the contribution. I found several blockers in the new annotation APIs:

1. EditorAnnotations::adjust_for_edit updates range decorations and inline widgets but not gutter markers. Inserting or deleting lines before a marker leaves it on the old logical row, contrary to the promised document anchoring. Please update marker anchors for edits and add newline insertion/deletion regressions.

2. Both layout_match_range and layout_range_corners reject a range unless it is wholly inside visible_range_offset. A range crossing the top or bottom viewport boundary therefore disappears while its middle is visible. Please clip to the visible byte range and test both boundaries, wrapping, and folds.

3. Inline widgets are painted after document layout without reserving space. A widget before suffix text overpaints that text, and the API accepts only text rather than the described non-textual element. Please either implement an actual layout-participating element contract or narrow the API/name/documentation to the behavior that can be supported, with UI integration coverage.

4. Gutter marker activation is pointer-only (on_mouse_down). Please provide a focus/keyboard action path and appropriate accessibility semantics so breakpoint-style commands do not depend on a mouse.

5. Adding GutterMarkerMouseDown to the shared public InputEvent breaks downstream exhaustive matches (the unrelated match updates in this PR demonstrate this). Please use an editor-specific event/callback or document and deliberately handle the compatibility strategy.

6. The paint path scans every stored annotation each frame; gutter layout additionally clones/sorts visible markers and repeatedly searches/sums visible lines. Please index/cull this work or provide measurements showing it remains acceptable for realistic diagnostic/search-sized collections.

Please add UI integration tests for marker activation and keyboard access, partially visible decorations, inline layout, wrapping/folding, and representative large collections. The existing range-adjustment unit tests and passing CI do not exercise these paths.

Security: PASS for the affected in-process rendering/event boundary.

Please address the findings above, then request my review again.

[huacnlee]

补充产品范围与公共 API 审查：

底层需求本身成立，但这三个能力目前并不具备相同的成熟度，不适合一起进入核心 Editor API。

• **Gutter marker：**适合作为 breakpoint、diagnostic、diff 和 bookmark 共用的核心能力，但抽象应该是通用的 gutter/lane，而不是固定为单个 22px icon lane。
• **Geometric range decoration：**需求合理，可以表达现有 TextDecoration 无法覆盖的几何效果；但应复用现有 collection ownership 和 tracked range 模型，而不是再增加一套全局替换 API。
• **Inline widget：**建议从本 PR 移除并推迟。当前实现只是覆盖绘制文字，不是参与布局的 widget。真正的 API 需要定义测量、空间占用、换行、hit testing、focus、键盘操作和 accessibility。

当前 API 还有以下结构性问题：

1. set_gutter_markers、set_range_decorations 和 set_inline_widgets 都会替换一个全局 Vec，多个独立 feature 会互相覆盖。请延续现有 TextDecorationCollection 模型，让每个 feature 持有生命周期独立的 collection/handle。
2. RangeDecoration 和 InlineWidget 都要求 ID，但 ID 不能用于 keyed reconciliation、定向更新/删除、bounds 查询或事件处理。要么让 ID 真正承担稳定 identity，要么不要在整体替换的数据中强制要求 ID。
3. logical row、byte range 和 byte offset 三种 anchor 的编辑语义不一致。建议统一为 tracked anchor/range，并明确插入边界 affinity/stickiness，以及删除、整篇替换、undo/redo、fold 和 formatting 时的行为。
4. styled Editor::render 会把 gutter renderer 写入 retained EditorState。这混合了 presentation 与 document state，也会在 render 阶段修改状态；同一个 state 被多个 view 使用时，不同 renderer 还会互相覆盖。Renderer 应保留在当前 element/skin，通过 presentation seam 传入 Base。
5. GutterMarker 一方面包含 icon token 和 tooltip，另一方面又要求 application renderer，造成 presentation ownership 重复，并在 Base 中固化了 marker 必须是 icon 的假设。Base 应只持有语义 identity、anchor 和 state，具体表现由 component 层负责。
6. 请使用 editor-specific event/callback，不要扩展所有 Input 共用的 InputEvent。对未来可能增加 variant 的 RangeDecorationStyle 等公共 enum，也应考虑 #[non_exhaustive]。
7. 公共模型不应过早固定为每行一个 marker、只有一个 lane。多个 owner 共存时会需要 lane identity、顺序/冲突策略，以及随 zoom/density 缩放的 geometry。

产品建议：接受 gutter marker 和 geometric range decoration 的需求方向；推迟 inline widget；先建立统一的、collection-owned、可跟踪编辑的 annotation 基础模型，再拆成较小的独立改动。产品范围仍需 maintainer 明确决定，不能仅凭实现完整度默认接受全部三个能力。

[feigeCode]

Thanks for the review. I've narrowed this PR to the shared annotation base and removed the other two features, then went through the findings one by one:

Scope now

Only the collection-owned tracked range decoration survives here. Gutter markers, gutter lanes, inline widgets, InputEvent::GutterMarkerMouseDown and the Editor gutter renderer projection are gone from this revision, so the shared InputEvent enum is no longer touched at all. git grep for GutterMarker / GutterLane / InlineWidget / gutter_lane / inline_widget over crates returns nothing.

Findings

1. Markers not anchored across edits — the marker anchor was part of the deferred gutter feature, so the newline insertion/deletion contract for markers is no longer in this PR. Range decorations keep the shared edit tracking and are covered by decoration_ranges_follow_text_edits and geometric_decorations_track_edits_history_replacement_and_owner_lifetime.

2. Partially visible ranges disappearing — fixed at the source: layout_match_range and layout_range_corners now clip to the visible byte range (range.start.max(visible_range_offset.start)..range.end.min(visible_range_offset.end)) and project through the shaped lines, so a range crossing the top or bottom boundary keeps its visible part. Coverage: geometric_decorations_clip_scrolled_viewport_and_cull_offscreen_ranges (both boundaries), geometric_decorations_use_shaped_wrap_boundaries_and_newline_cells, geometric_decorations_include_crlf_boundaries, geometric_decorations_project_folds_without_changing_tracked_ranges.

3. Inline widgets — out of this PR. I agree the current version was a paint-time text overlay rather than a layout-participating element; measure / reserved space / wrapping / hit testing / focus / accessibility is a separate change with its own contract.

4. Gutter marker keyboard and accessibility — deferred together with the gutter feature.

5. InputEvent compatibility — resolved by removing the variant; this revision does not change the shared event enum, so no downstream exhaustive matches are affected.

6. Per-frame full scan — a per-collection balanced interval index (subtree max-end) is consulted once per visible, non-folded buffer span, instead of walking every stored annotation. set / append rebuild that collection's index; edits update the affected entries linearly without re-sorting. interval_index_culls_large_collections_even_with_a_spanning_range builds 100,001 decorations plus one document-spanning decoration, and interval_index_matches_linear_reference_for_overlaps_and_mutations cross-checks the index against a linear reference for overlaps and mutations.

From the second review

• The global set_range_decorations replacement API is gone; each feature holds RangeDecorationCollection (set / append / clear / dispose / get_ranges) and collections do not overwrite one another.
• Public decoration IDs are gone — the collection handle owns lifetime, so IDs no longer pretend to be a stable identity.
• Text and geometric decorations share one TrackedDecoration abstraction for UTF-8 normalization and edit affinity (insertion at either edge does not expand, insertion inside does, replacement clips overlapping anchors, deletion removes empty ranges, set_value / replace_all / formatting / undo-redo apply the same transforms; decorations are not part of undo history).
• The styled Editor::render gutter renderer projection into retained EditorState is removed with the gutter feature, so nothing is written back to document state during render.
• RangeDecorationStyle is #[non_exhaustive].

Follow-ups (not here)

• Gutter / lane abstraction with lane identity, ordering and a keyboard + accessibility contract.
• Inline widgets as real layout-participating elements.

The branch is currently 5 commits behind main; none of those commits touch the files in this PR, so the diff is unaffected.

@huacnlee Addressed the findings above — could you take another look when you have a moment? (Fork accounts can't use the review-request button, so mentioning you here instead.)

[zanmato]

Could we snap the stroke path to pixels? Otherwise it looks thinner/thicker in some areas:

Also it would be nice to have a Block style, like datagrip, a rectangle the width of the longest line in the range: