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.
Description
Add a low-level rendering primitive to
CodeEditTextViewfor 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:
InlineSuggestionvalue type (a documentoffsetplus thetextto show, which may be multi-line).TextView.setInlineSuggestion(_:at:),TextView.setInlineSuggestion(_:)(anchored at the primary caret), andTextView.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
textStorageor 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
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:
CodeEditTextViewprovides the rendering primitive,CodeEditSourceEditorcoordinates request/accept/dismiss, andCodeEditwires up the provider. This issue covers only theCodeEditTextViewrendering 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 inCodeEditTextView?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/CodeEditintegration.