Preserve inline formatting while typing - #31
Conversation
|
| Filename | Overview |
|---|---|
| docmostly/Features/Editor/NativeRichEditorViewModel+BlockEditing.swift | Introduces collapsed-selection mark tracking while retaining undoable attributed-text mutations for selected ranges. |
| docmostly/Features/Editor/NativeEditorTextMutation.swift | Applies optional typing marks to replacement text and extends focus reconciliation for responder handoffs. |
| docmostly/Features/Editor/NativeEditorTextInputView+iOS.swift | Synchronizes UIKit typing attributes, editability, focus handoffs, and typing-context invalidation. |
| docmostly/Features/Editor/NativeEditorTextInputView+macOS.swift | Synchronizes AppKit typing attributes after selection updates and adds equivalent focus and context handling. |
| docmostly/Features/Editor/NativeEditorInlineMark.swift | Adds mark activation queries, explicit setters, selection-derived active marks, and mutually exclusive baseline marks. |
| docmostly/Features/Editor/NativeEditorBlockRow.swift | Keeps native text surfaces mounted for editable block kinds while controlling platform editability separately. |
| docmostlyTests/Editor/NativeRichEditorInlineTypingTests.swift | Covers collapsed-selection mark toggling and selected-range formatting behavior. |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart LR
A[Collapsed editor selection] --> B[Toggle inline mark]
B --> C[Store marks in inline typing context]
C --> D[Synchronize native typing attributes]
D --> E[User inserts text]
E --> F[Apply marks to inserted range only]
F --> G[Update attributed document]
H[Explicit cursor movement] --> I[Invalidate typing context]
Reviews (1): Last reviewed commit: "Preserve inline formatting while typing" | Re-trigger Greptile
There was a problem hiding this comment.
2 issues found across 18 files
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="docmostly/Features/Editor/NativeEditorBodyView.swift">
<violation number="1" location="docmostly/Features/Editor/NativeEditorBodyView.swift:65">
P2: Pasting or otherwise activating a non-text block leaves the previous text view as first responder, because every inactive text row treats any non-nil active block as a focus handoff. Limit responder preservation to an editable target so keyboard input cannot remain in the old block after a table/media block becomes active.</violation>
</file>
<file name="docmostly/Features/Editor/NativeEditorTextInputView+iOS.swift">
<violation number="1" location="docmostly/Features/Editor/NativeEditorTextInputView+iOS.swift:42">
P2: Programmatic focus or bound-selection updates clear the just-configured `typingAttributes`, so the next input can use UIKit’s default/caret attributes instead of `typingInlineMarks`. Configure after `applySource`/`updateFromBoundBlock` and their selection synchronization, matching the macOS ordering.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
| focusRequestID: textInputFocusRequest?.blockID == block.id | ||
| ? textInputFocusRequest?.id | ||
| : nil, | ||
| retainsResponderDuringFocusHandoff: viewModel.activeBlockID != nil && |
There was a problem hiding this comment.
P2: Pasting or otherwise activating a non-text block leaves the previous text view as first responder, because every inactive text row treats any non-nil active block as a focus handoff. Limit responder preservation to an editable target so keyboard input cannot remain in the old block after a table/media block becomes active.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At docmostly/Features/Editor/NativeEditorBodyView.swift, line 65:
<comment>Pasting or otherwise activating a non-text block leaves the previous text view as first responder, because every inactive text row treats any non-nil active block as a focus handoff. Limit responder preservation to an editable target so keyboard input cannot remain in the old block after a table/media block becomes active.</comment>
<file context>
@@ -62,6 +62,8 @@ struct NativeEditorBodyView: View {
focusRequestID: textInputFocusRequest?.blockID == block.id
? textInputFocusRequest?.id
: nil,
+ retainsResponderDuringFocusHandoff: viewModel.activeBlockID != nil &&
+ viewModel.activeBlockID != block.id,
isSelected: viewModel.selectedBlockID == block.id,
</file context>
| textView.backspaceAtStartAction = { [weak coordinator = context.coordinator] in | ||
| coordinator?.mergeBlockBackward() ?? false | ||
| } | ||
| context.coordinator.configure(textView) |
There was a problem hiding this comment.
P2: Programmatic focus or bound-selection updates clear the just-configured typingAttributes, so the next input can use UIKit’s default/caret attributes instead of typingInlineMarks. Configure after applySource/updateFromBoundBlock and their selection synchronization, matching the macOS ordering.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At docmostly/Features/Editor/NativeEditorTextInputView+iOS.swift, line 42:
<comment>Programmatic focus or bound-selection updates clear the just-configured `typingAttributes`, so the next input can use UIKit’s default/caret attributes instead of `typingInlineMarks`. Configure after `applySource`/`updateFromBoundBlock` and their selection synchronization, matching the macOS ordering.</comment>
<file context>
@@ -33,6 +39,7 @@ struct NativeEditorTextInputView: UIViewRepresentable {
textView.backspaceAtStartAction = { [weak coordinator = context.coordinator] in
coordinator?.mergeBlockBackward() ?? false
}
+ context.coordinator.configure(textView)
context.coordinator.applySource(to: textView)
context.coordinator.updateFocus(textView)
</file context>
Summary
Validation
git diff --checkswiftlint lint --strict --quiet --cache-path /private/tmp/docmostly-swiftlint-cacheXcode builds and tests were not run, per repository instructions.