CodeEditApp / CodeEditApp/CodeEditSourceEditor
Inline completion (ghost text) coordination layer
- 主要语言
- Swift
- 星标
- 719
- 派生
- 160
- PR 合并指标
- 30 天内没有已合并 PR
描述
### Description
Add an inline completion (ghost text) coordination layer to `CodeEditSourceEditor`, built on the inline suggestion rendering primitive in `CodeEditTextView`. This gives the editor a provider-agnostic way to request, show, accept, cycle, and dismiss inline AI suggestions (the GitHub Copilot UI pattern).
Proposed API:
- `InlineCompletionDelegate`: a `@MainActor` protocol a host conforms to. `inlineCompletionsRequested(textView:cursorPosition:) async -> [InlineCompletionItem]` returns suggestions; optional `inlineCompletionDidShow/Accept/Dismiss` hooks report lifecycle.
- `InlineCompletionItem`: the suggestion model (insert text plus the range it applies to).
- `TextViewController` methods: `requestInlineSuggestion()` (debounced), `setInlineSuggestions(_:selectedIndex:)`, `acceptInlineSuggestion()`, `dismissInlineSuggestion()`, `selectNext/PreviousInlineSuggestion()`.
- Behavior: requests are debounced and skipped while the completion popup is visible (ghost text and popup never co-exist); Tab accepts when a suggestion is active; moving the cursor or editing dismisses the ghost text.
### Alternatives Considered
- Putting this logic in the app target (`CodeEdit`) directly. Rejected because the request/accept/dismiss lifecycle is tightly coupled to the editor's cursor, selection, and key handling, which live here. Keeping it in `CodeEditSourceEditor` lets any host provide completions through a small delegate, rather than each host re-implementing the lifecycle.
- Mutating the document to preview suggestions. Rejected; the underlying `CodeEditTextView` primitive renders ghost text as an overlay without touching text storage, so previews never pollute undo or layout.
### Additional Context
This is the middle layer of a planned native inline-completion feature for the CodeEdit stack: `CodeEditTextView` provides the rendering primitive (CodeEditApp/CodeEditTextView#124), `CodeEditSourceEditor` (this issue) coordinates the lifecycle, and `CodeEdit` wires up a concrete provider such as GitHub Copilot.
I have a working, documented implementation with unit tests covering request/show, accept, dismiss, cycling, Tab-accept gating, and ghost-text clearing on cursor move and edit. It builds and tests pass via `xcodebuild ... clean test` (against the `CodeEditTextView` change above), and SwiftLint is clean. Would the maintainers welcome this in `CodeEditSourceEditor`?
### Screenshots
The user-visible ghost text is shown by the app-level integration in `CodeEdit`; this layer is the coordination API and is covered by unit tests.
贡献指南
这个仓库没有索引到贡献指南
调研方向
Start in CodeEditSourceEditor’s TextViewController and read the inline suggestion rendering primitive in CodeEditTextView, then review the proposed InlineCompletionDelegate and InlineCompletionItem API. Run the existing unit tests with the documented xcodebuild clean test flow; done means request, display, accept, dismiss, cycle, Tab gating, and cursor/edit clearing behave as described.
由索引模型根据 Issue 内容生成。
评估
- 技术栈
- swift
- 领域
- developer-experience, tooling
- Issue 类型
- 功能
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 活跃度
- 冷清
- 描述清晰度
- 基本清楚
- 新手友好度
- 32/100