CodeEditApp / CodeEditApp/CodeEditTextView

Inline suggestion (ghost text) rendering primitive

未關閉
#124 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視
主要語言
Swift
星號
182
分支
54
PR 合併指標
30 天內沒有已合併 PR

描述

### Description

Add a low-level rendering primitive to `CodeEditTextView` for inline "ghost text" suggestions: text drawn after the caret that previews content the user has not typed yet (the same UI pattern as GitHub Copilot, Xcode predictive completion, and similar inline AI suggestions).

The proposed API is small and rendering-only:

- A `InlineSuggestion` value type (a document `offset` plus the `text` to show, which may be multi-line).
- `TextView.setInlineSuggestion(_:at:)`, `TextView.setInlineSuggestion(_:)` (anchored at the primary caret), and `TextView.clearInlineSuggestion()`.

Key design point: a suggestion is purely a rendering hint. It is drawn as a sibling overlay anchored at the caret and never mutates `textStorage` or shifts real text layout, so it cannot corrupt the document or interfere with editing, undo, or selection. This keeps the primitive safe and makes it a clean foundation that higher layers can drive.

### Alternatives Considered

- Inserting the suggestion as real (styled) text and removing it on reject. Rejected because it mutates the text storage, pollutes undo, and risks desyncing layout and selection.
- Building the feature entirely in a downstream package. Rejected because the caret geometry and layout information needed to position ghost text correctly live in `CodeEditTextView`, so the rendering primitive belongs here. Higher-level packages should only decide what text to show and when.

### Additional Context

This is intended as the foundation for native inline AI completions (for example GitHub Copilot) in the CodeEdit stack: `CodeEditTextView` provides the rendering primitive, `CodeEditSourceEditor` coordinates request/accept/dismiss, and `CodeEdit` wires up the provider. This issue covers only the `CodeEditTextView` rendering layer.

I have a working, documented implementation with unit tests (overlay rendering, multi-line suggestions, and a check that the suggestion never mutates text storage). It builds and tests pass via `xcodebuild ... clean test`, and SwiftLint is clean. I am happy to open it as a PR for review. Would the maintainers welcome this in `CodeEditTextView`?

### Screenshots

This layer is a non-visual API primitive; the user-visible ghost text appears once a higher layer drives it. The rendered result can be shown in the downstream `CodeEditSourceEditor` / `CodeEdit` integration.

貢獻指南

這個儲存庫沒有索引到貢獻指南

研究方向

Start in CodeEditTextView and inspect its caret geometry and layout/rendering path; the issue does not name a file or test target. Run the existing xcodebuild clean test suite and SwiftLint, then verify the InlineSuggestion API renders single- and multi-line overlays without changing textStorage or editing state.

由索引模型根據 Issue 內容生成。

評估

技術堆疊
swift
領域
desktop, devtools
Issue 類型
功能
難度
4/5
預估耗時
3-5 天
活躍度
冷清
描述清晰度
基本清楚
新手友好度
48/100

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。