feat(transcription): re-edit existing @mention by pre-filling the search input #628
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Context
Follow-up split off from #380 ("decouple @mention display text from person search").
Issue #380 acceptance criterion 7 reads:
While implementing #380 we verified empirically that Tiptap's suggestion plugin (
@tiptap/extension-mention@3.23.4) does not fireonStart/onUpdatewhen a cursor enters an existing mention node — the suggestion is only triggered by typing a fresh@. AC-7 was therefore split out of #380 per the original triage decision ("If it's free include it, otherwise create issue") and lands here.User Story
As a transcriber, when I move the cursor into an already-saved
@mention, I want the search dropdown to re-open with the search field pre-filled with the stored display text, so that I can correct or re-link the person without retyping the mention from scratch.Acceptance Criteria
Given the cursor is positioned inside an existing
@mentionnode, when the position settles (selection update), then the mention dropdown opens at that mention.Given the dropdown opened for an existing mention, when it appears, then the search input is pre-filled with the mention's stored
displayName.Given the search input has been pre-filled from an existing mention, when the user picks a different person from the dropdown, then the existing mention node's
personIdis replaced; the displayed text remains exactly what the user types (#380 AC-1 invariant).Given the search input has been pre-filled from an existing mention, when the user closes the dropdown via Escape, then the mention node is unchanged.
Given the search input has been pre-filled and edited, when the user picks a person, then the linked
personIdupdates AND the displayed text remains exactly what the user originally typed (the #380 AC-1 "display text stays exactly as typed" invariant takes precedence over the search input's content).AC-5 rationale: previously the AC contained an (a) / (b) ambiguity with the recommended answer hidden in Open Decisions. Folded back into the AC list per comment #11033 — Elicit on PR #629 #10962. If (b) "update display text to search input value" is ever wanted, file a sibling issue rather than reintroduce the branch here.
NFR Notes
<span class="mention-token">isfont-medium underlinetext, which is taps-through at ~22 px. Consider addinginline-block min-h-[44px]or similar for tablet ergonomics.selectionUpdatelistener fires on every caret move — the mention-detection check must be O(1) (readselection.$anchor.parent.type.name), not a tree walk.Implementation Notes
The hard work is in
frontend/src/lib/shared/discussion/PersonMentionEditor.svelte:editor.on('selectionUpdate', ...)that checks if the parent node at the caret ismention.MentionDropdowndirectly with the mention's attributes).displayNameaseditorQueryso the existing #380 mirror-then-debounce path renders correctly.personId(display text unchanged per AC-5).References:
PersonMentionEditor.sveltedocumenting the suggestion lifecycle.Out of Scope
AC-5 — promote Open Decision to explicit AC (Elicit on PR #629 #10962)
Elicit flagged on PR #629 that AC-5 is currently a multi-branch sentence with the answer hidden in Open Decisions — which leaves the implementer staring at the same sticky-takeover ambiguity Felix raised in round 1.
Suggested AC-5 rewrite (defaulting to the #380 AC-1 invariant):
This collapses the (a) / (b) branch into the single behaviour the recommend already nominates, and drops the Open Decision entirely — moving it to the AC list. If you ever do want (b) later, it becomes its own issue rather than a hidden branch in this one.
No edit to the issue body required from my side — flagging as a suggested one-line update before #628 enters refinement.