Ausgeschriebenes `:smile:` automatisch ersetzen

[usekaneo]

Nur das Dropdown wandelt einen Shortcode in ein Emoji um. Wer :smile: ausschreibt, behält den Shortcode im Text.

Aufgabe: Ersetzen auch beim Tippen — mit der Vorsicht, die docs/13 nennt: darf nicht in Konstruktionen wie a:b:c oder in Code-Spans feuern. Laut Doc wartet der Punkt bewusst auf einen Anlass, also niedrig priorisiert.

Quelle: docs/13-editing.md „Open"
Betroffen: src/ui/emoji.ts

---

_{Task: w1qmx7ypwhrh7zc6wcykwe5q}

[usekaneo]

CON-20

[usekaneo]

**** commented:

Technical refinement

Status: small, self-contained editor change. The whole difficulty is the guard rails docs/13 already names (a:b:c, code spans); the replacement itself is one transaction.

What exists today

• emojiCompletion (src/ui/editor-complete.ts:69-94) opens the : dropdown, anchored to (?:^|[\s(]), and inserts the character via the completion's apply. A typed-out shortcode is left untouched.
• EMOJI (src/ui/emoji.ts) is the curated list ({ name, char, keywords }); searchEmoji ranks it. Names with _ and +/- exist (slightly_smiling_face, thumbsup).
• The editor is assembled in src/ui/MarkdownEditor.tsx; syntaxTree is already imported there, so code-span detection is available.
• docs/13 lists the feature as Open and states the exact hazard: 'risks firing inside things like a:b:c, so it waits for a reason'.

Approach

1. Pure matcher first. New src/ui/editor-emoji.ts exports matchShortcode(text: string, pos: number): { from: number; to: number; char: string } | null. Rules:
   • the token ends exactly at pos and is :name:;
   • the opening colon needs a boundary before it — start of text, whitespace or (, the same set the dropdown uses;
   • the closing colon needs a boundary after it — end of text, whitespace or closing punctuation . , ; : ! ? ) — so a:b:c, 12:30:45 and URLs never match;
   • name must exactly match an entry in EMOJI (case-insensitive), so unknown :nope: stays as written;
   • an escaped \:smile: does not match;
   • only for a collapsed selection.
     Being pure means every one of these is a unit test, not an editor test.
2. Hook it into the editor. In MarkdownEditor, add a CodeMirror extension that reacts to a user input inserting : — an inputHandler or a ViewPlugin watching update.transactions with isUserEvent('input'). When matchShortcode returns a range:
   • skip if syntaxTree(state).resolveInner(from) sits inside InlineCode, FencedCode/CodeBlock or a URL/autolink node (walk ancestors);
   • otherwise dispatch one transaction { changes: { from, to, insert: char }, selection: cursor(from + char.length), userEvent: 'input.emoji' }.
     A single transaction means undo restores :smile:, and the custom userEvent keeps the plugin from re-entering.
3. Coexistence with the dropdown. Picking from the dropdown inserts the character directly and must not be double-handled; confirm in a DOM test. Typing the final : while the dropdown is open is fine — the replacement changes the doc and the completion re-evaluates.
4. No new setting. The escape (\:) and code spans are the opt-outs; a preference toggle can come later if it is ever asked for.

Subtasks

• src/ui/editor-emoji.ts: matchShortcode + the CodeMirror extension
• Wire the extension into MarkdownEditor next to the existing extensions
• Code-span/URL guard via syntaxTree
• Unit tests for every matcher rule; one jsdom editor test for typing + undo and one for the dropdown path
• Docs: docs/13 Open item removed, section 'Emoji — :' extended

Acceptance criteria

• Typing :smile: (with a valid boundary) inserts 😄 and removes the shortcode in one undoable step.
• a:b:c, 12:30, https://x:y, an unknown :nope: and an escaped \:smile: are left exactly as typed.
• Inside an inline code span or a fenced code block nothing is replaced.
• Picking from the dropdown still works unchanged.
• Undo after a replacement restores the literal shortcode.

Risks / notes

• False positives are the whole risk. When in doubt, do not replace: an untouched :smile: is a small annoyance, a mangled 12:30 or URL is a real bug.
• syntaxTree on the keystroke is cheap, but resolve against the new state after the change, or the inline-code node at the cursor may not exist yet.
• Keep the matcher independent of the extension so the rules stay unit-testable without jsdom.

Depends on / relates to

docs/13 (editor model), emojiCompletion (shared boundary rule — extract it if the two drift).

[usekaneo]

**** commented:

Reviewed in worktree .worktrees/con-20 (feat/con-20-emoji-shortcode-on-typing @ 2085dd3). Verification run for this review on that worktree: npm run typecheck, npm run lint, npm test, npm run build — all four pass.

Review — CON-20: Automatically replace a typed-out :smile:

Verdict: ⚠️ Approve with nits — the feature works and the primary risk the ticket names (a:b:c-style false positives) is handled robustly; one documented limitation (an inline code span still being typed) falls short of the literal acceptance criterion and needs a small follow-up or an explicit sign-off, and the test suite does not actually pin the boundary guard it is meant to protect.

Summary

The change adds a CodeMirror inputHandler (src/ui/editor-emoji-replace.ts, registered at src/ui/MarkdownEditor.tsx:738) that intercepts a typed : when the text before the cursor ends in a known emoji shortcode and replaces :name plus the typed colon with the emoji character in a single transaction. Three guards implement the docs/13 caution: a word-boundary test on the opening colon, a curated-list lookup, and a syntax-tree code guard. It therefore attacks the ticket's core ask — typing :smile: now yields 😄, not only picking from the dropdown — and reuses the existing EMOJI list rather than growing a second vocabulary. The ticket's "Betroffen: src/ui/emoji.ts" hint was translated into a new module; emoji.ts is unchanged and reused, which is fine.

Acceptance criteria

• A shortcode typed out in full is converted by its closing colon — editor-emoji-replace.ts:102-115, wired at MarkdownEditor.tsx:738; tests editor-emoji-replace.test.ts:58-61 and :108-113.
• Does not fire in a:b:c-style constructs — the opening colon must follow line start, whitespace or an opening bracket (editor-emoji-replace.ts:87); tests :63-67. (The tests themselves are weak here — see F2 — but I traced the guard and it does hold for a:b:c, 12:30:45 and host:8080/x:y:.)
• [~] Does not fire in code spans — closed code is covered (editor-emoji-replace.ts:91, tests :92-98), but a code span still being typed is not: see F1.
• Unknown shortcodes stay text — editor-emoji-replace.ts:89; test :73-76.
• No dropdown regression — closeCompletion at editor-emoji-replace.ts:113, and the handler is registered before autocompletion() (MarkdownEditor.tsx:738-748).

Findings

Must fix or get an explicit sign-off

F1 — major — Fires inside an inline code span while it is still being typed.
editor-emoji-replace.ts:91: if (inCode(state, open)) return null. The guard only knows code the parser has already recognised. Type :smile: — at the moment the closing : is typed the document is :smile, and I dumped the lezer tree for exactly that text: it is Paragraph with no InlineCode node, so inCode returns false and :smile becomes 😄, leaving 😄 wrapped in backticks. The test at :96-97 only covers an already-closed span. The file comment admits this (:42-45) and docs/13 repeats it (:429-433), but the ticket says the replacement must not fire in code spans. It is a real but narrow gap: it silently corrupts a code literal the writer intended to keep.
Fix: before accepting, scan backward from open to line.from for an odd number of backtick runs and bail if one is unmatched; or, if the team prefers the documented limitation, record it on the ticket explicitly and add a test that pins the current firing-inside behaviour so it cannot drift unnoticed.

Nice to have

F2 — minor (tests) — The negative boundary tests are vacuous.
editor-emoji-replace.test.ts:64-66:

expect(closing('a:b')).toBeNull()
expect(closing('12:30')).toBeNull()
expect(closing('https://host:8080')).toBeNull()

In all three the captured name (b, 30, 8080) is not in EMOJI (src/ui/emoji.ts:19-260), so the name guard at editor-emoji-replace.ts:89-90 already returns null. Delete the boundary guard at :87 and every one of these still passes — the guard this ticket is about is not tested on its negative side. Use known names after a word character instead, e.g. closing('a:smile'), closing('12:rocket'), closing('host:cat'), and add the ticket's own a:b:c / 12:30:45 examples.

F3 — minor (docs) — The undo claim is wrong.
docs/13-editing.md:435-436: "one Ctrl+Z brings :smile: back whole", echoed at editor-emoji-replace.ts:99-100. The closing colon is consumed by the input handler and never enters the document, so undo cannot restore it. I verified with history()/undo from @codemirror/commands against the exact transaction the handler dispatches: with default grouping one undo reverted the :smile typing and the replacement together (to an empty document in a clean buffer); with newGroupDelay: 0 it restored :smile — never :smile:. Fix: reword to "one Ctrl+Z removes the emoji together with the shortcode it replaced", or isolate the replacement in history if the literal behaviour is wanted.

F4 — minor (docs) — The paste sentence overstates what happens.
docs/13-editing.md:416-417 says a line pasted from a chat log "stops being the one place … that still shows :tada:". emojiReplacement returns null unless text === ':' && from === to (editor-emoji-replace.ts:75) — pasted text is never scanned; only re-typing the final colon converts. The file comment states this correctly (:12-14); the doc paragraph should keep that "retyped" qualifier.

F5 — nit — "That is the dropdown's own rule" is imprecise.
editor-emoji-replace.ts:21-25 and docs/13-editing.md:422-423 claim the boundary rule is the dropdown's. The dropdown matches (?:^|[\s(]) (editor-complete.ts:70); the new guard is [\s([{] (editor-emoji-replace.ts:87) — broader. Harmless, but the comments should say "the dropdown's rule, extended to [ and {".

No other correctness or regression problem found. The handler is ordered before liveMarkdown's blockEdges (MarkdownEditor.tsx:738-739), so it wins; autocompletion() registers no inputHandler; closeCompletion is safe with no autocompletion extension mounted (it reads completionState with required = false); and normaliseTaskMarker (MarkdownEditor.tsx:605-635) only rewrites non-breaking spaces inside task markers, so it cannot alter the emoji transaction.

Tests

The suite is real and would fail against a dummy: the positive cases (:58-61), case-insensitivity (:78-79), the paste/selection exclusions (:82-90), the caret assertion (:115-124) and the code-guard cases (:92-98) all exercise behaviour that does not exist without the feature. Beyond F2:

• The code-guard tests pre-force the parse with ensureSyntaxTree (:29-31), while production calls syntaxTree(state) bare (editor-emoji-replace.ts:51). That difference is worth checking — a code block the background parser has not reached yet (far down a long document) may not suppress the replacement.
• No test for the 64-character look-back window (editor-emoji-replace.ts:82) or for a shortcode mid-line with text after the cursor.
• The wiring test calls the inputHandler facet directly because jsdom cannot drive CodeMirror's text input (:110-111); that is a fair compromise and it still asserts the registration.

Docs

docs/13-editing.md was updated in the right place — the new paragraph at :413-436 and the "Auto-replacing a typed-out :smile:" bullet removed from the Open list (:609-622) — and the new file is referenced correctly. Two sentences are inaccurate (F3, F4) and one is imprecise (F5). docs/10-roadmap.md:182 still describes only the dropdown; it remains true and was not in scope.

What is good

• The decision logic is a pure, exported function (emojiReplacement) with the extension as a thin wrapper — easy to read, and the guards are testable as text-in/decision-out.
• Using inputHandler rather than a transaction filter keeps the typed : out of the document entirely, and the code guard reuses the node set already established in editor-slash.ts (CODE_NODES, editor-emoji-replace.ts:47).
• The curated list is reused (BY_NAME built from EMOJI, :35), and the comments explain why each guard exists rather than restating the code.
• closeCompletion(view) (:113) is a thoughtful detail: the : dropdown would otherwise stay open over text that no longer exists.
• The negative-case emphasis in the tests matches the ticket's stated risk, even if F2 shows the boundary cases need better names.

[usekaneo]

**** commented:

Worktree .worktrees/con-20 (feat/con-20-emoji-shortcode-on-typing, uncommitted on top of 2085dd3). Verification after the changes below: npm run typecheck, npm run lint, npm test (45 files, 454 tests), npm run build — all four pass.

Response to the review — findings addressed

Every claim was re-checked against the code before acting on it. All five numbered findings were confirmed accurate and are fixed. One unnumbered concern from the Tests section was confirmed real but pre-existing and codebase-wide, and is reported below as open rather than fixed unilaterally.

Files changed: src/ui/editor-emoji-replace.ts, src/ui/editor-emoji-replace.test.ts, docs/13-editing.md.

F1 — major — fires inside an inline code span still being typed — fixed

Confirmed exactly as described: at the moment the closing colon is typed the line reads `a :smile, lezer parses it as a plain Paragraph, inCode returns false and the code literal is eaten.

Fixed with inUnclosedCodeSpan() (src/ui/editor-emoji-replace.ts:76-92), called alongside inCode at :125. It implements the review's suggested fix — a backward scan from the opening colon to line.from — using CommonMark's own pairing rule: a run of n backticks is closed by the next run of exactly n, runs of other lengths in between are literal text, and an unclosed run left over means the caret is inside a span. That rule (rather than a plain odd/even count) is what makes ``a ` b`` come out right.

Scope is bounded to the caret's line, deliberately. A span can run across lines inside a paragraph, but then only the opening line is misread and the error falls the safe way — an un-replaced :smile: is an annoyance, a mangled code literal is a bug.

Regression test proven against the unfixed code. editor-emoji-replace.test.ts:129-142. I temporarily removed || inUnclosedCodeSpan(...) from :125 and re-ran: the test fails with expected { from: 3, to: 9, insert: '😄' } to be null. Restored afterwards and re-verified by md5. It feeds real text through the real emojiReplacement, not a regex in isolation, and covers both the still-open span (`a :smile, write `:smile) and the two cases that must still convert (a closed span earlier on the line, and a double-backtick run enclosing a single one).

F2 — minor — the negative boundary tests were vacuous — fixed

Confirmed. In closing('a:b'), closing('12:30') and closing('https://host:8080') the captured names b, 30, 8080 are not in EMOJI, so the name guard answered first and the boundary guard at :121 was never reached.

Rewritten at editor-emoji-replace.test.ts:64-74 to use names we really know, so the boundary rule is the only thing that can reject them: a:smile, a:b:smile, 12:30:cat, https://host:smile, host:8080/x:cat — including the ticket's own a:b:c and 12:30:45 shapes.

Proven against the unfixed code, which is the point of the finding: I deleted the boundary guard line entirely and re-ran. Previously zero tests failed; now two do — the rewritten boundary test (expected { from: 1, to: 7, insert: '😄' } to be null) and the look-back test below. Restored and re-verified.

A second test was added at :76-83 for the 64-character look-back window, which the review noted was untested. The window is a slice, not a line start, so a word running past it must not come out looking like a boundary; the guard reads the character in front of the colon from the document, so it holds. Pinned both ways: x.repeat(80) + :smile stays text, x.repeat(80) + :smile converts. A mid-line case with text still standing behind the caret was added at :85-89, also noted as missing.

F3 — minor — the undo claim was wrong — fixed (docs), with a residual decision left open

Confirmed. The closing colon is consumed by the inputHandler and never enters the document, so no Ctrl+Z can produce :smile:. The old wording in docs/13-editing.md and the file comment both promised more than the code delivers.

Reworded to what actually happens: docs/13-editing.md:436-438 now says one Ctrl+Z removes the emoji together with the shortcode it replaced, and cannot put :smile: back whole because the closing colon never entered the document. The file comment at editor-emoji-replace.ts:130-141 says the same and names the reason — the change is annotated input.type like the typing around it, so history groups them.

A test pins what undo can actually give back (editor-emoji-replace.test.ts:152-186), using history({ newGroupDelay: 0 }) to keep the steps apart; with default grouping the single undo takes the preceding typing with it too.

Open, for a decision: the review's alternative was to isolate the replacement in history so the literal :smile survives one Ctrl+Z. That is a behaviour choice about undo granularity, not a bug, so it is documented and tested as-is rather than changed here. Say the word if the isolated-undo behaviour is wanted.

F4 — minor — the paste sentence overstated what happens — fixed

Confirmed: emojiReplacement returns null unless text === ':' && from === to (:109), so pasted text is never scanned.

docs/13-editing.md:413-418 now keeps the qualifier the file comment always had: it is the typed colon that converts, not the text, and a line pasted out of a chat log keeps its :tada: until somebody retypes that last colon.

F5 — nit — "the dropdown's own rule" was imprecise — fixed

Confirmed: the dropdown matches (?:^|[\s(]) (editor-complete.ts:70), the new guard is [\s([{] — broader. Both editor-emoji-replace.ts:21-26 and docs/13-editing.md:424-427 now say "the dropdown's rule, extended to [ and {". The stale limitation paragraph that F1 made untrue was removed from the CODE_NODES comment at the same time, and the comment's cross-reference corrected to NO_MENTION in markdown-live.ts.

Tests section — ensureSyntaxTree vs bare syntaxTree — real, but pre-existing and codebase-wide; reported open, not fixed

This was the one claim worth measuring, and the review was right to flag it. I probed it with a throwaway test (since deleted): a long document ending in a fenced code block, a real EditorView, no ensureSyntaxTree pre-forcing — i.e. the production path.

document	doc.length	syntaxTree().length	node at caret	replacement
~1.5 KB	1560	1560	CodeText	null — suppressed correctly
~131 KB	130910	130890	Document	fires inside the fenced block
~669 KB	668910	668890	Document	fires inside the fenced block

So on a long document the lazily-parsed tree stops short of the caret, resolveInner returns Document, inCode returns false, and the replacement fires inside a fenced code block.

Why it is not fixed here. Bare syntaxTree(state) is the established pattern across this whole editor, not something CON-20 introduced: MarkdownEditor.tsx:637 (inList, the Tab-in-list guard), markdown-live.ts:268/527/542/557 (the live-decoration engine) and editor-table.ts:975/1006/1028 all read it the same way, and nothing outside tests uses ensureSyntaxTree. The exposure is a property of the editor's lazy parsing, and every tree-reading guard in it shares the exposure. Two further caveats on the measurement: jsdom has no layout, so its viewport is degenerate, whereas a real browser parses the viewport the caret sits in — the numbers above are likely a worst case rather than the common one. And the only fixes available are trades I should not make unilaterally: ensureSyntaxTree with a time budget puts parse latency on every keystroke, and treating an unparsed tree as "unknown, so refuse" would silently disable the feature on long pages.

I also deliberately did not add a test pinning the current firing-inside behaviour here. It would be asserting a third-party lazy-parse heuristic as correct, and it would break on a CodeMirror upgrade that changes parse scheduling — pinning a behaviour we do not want, in a way that is brittle. Recording the measurement on the ticket is the more honest guard.

Recommend a separate ticket for the editor-wide question: whether tree-reading guards should force a parse near the caret, and at what latency budget.

Commands run

From the worktree, after all changes:

• npm run typecheck — pass (tsc --noEmit, exit 0)
• npm run lint — pass (eslint ., exit 0)
• npm test — pass, 45 files / 454 tests, no failures and no flakes on this run
• npm run build — pass, built in 3.77s (the >500 kB chunk warning is pre-existing and unrelated)

src/ui/editor-emoji-replace.test.ts alone: 14 tests, all passing.

Nothing is committed or staged — the changes sit in the working tree for review.