openclaw - 💡(How to fix) Fix emotion-tags: line-start `[label1][label2]` ambiguity between emotion-pair and markdown reference link [1 participants]

Summary

isSecondLabelInMarkdownReferenceLink() and isFollowedByMarkdownReferenceLink() in src/shared/text/emotion-tags.ts gate reference-link detection on hasNonWhitespaceBeforeOnLine. At line start, [fast][1] is mis-classified as adjacent emotion tags and stripped to [1]. Reported by Copilot on PRs #72229 and #72266.

The simple suggested fix (drop the hasNonWhitespaceBeforeOnLine guard) breaks two existing tests in src/shared/text/emotion-tags.test.ts:

• [warmly][softly] hello there → expected to strip both as adjacent emotion tags
• [fast][softly] go now. → expected to strip both as adjacent emotion tags

Tried-and-rejected heuristic

Drop the guard, but only count the pair as a reference link if the SECOND label is NOT in EMOTION_TAG_WORDS.

This handles [fast][1] ✓, [clear][docs] ✓, [warmly][softly] ✓, [fast][softly] ✓ — but breaks the existing test on line 57:

const allowlistedNamedReference = stripEmotionTags("See [fast][clear] before choosing.");
expect(allowlistedNamedReference).toEqual({
  text: "See [fast][clear] before choosing.",
  changed: false,
});

[fast][clear] is preserved here as a reference link even though clear is in EMOTION_TAG_WORDS. The test treats reference-link semantics as winning when there's leading non-whitespace; the heuristic above can't tell [fast][clear] (reference) apart from [fast][clear] (emotion pair) from labels alone.

What a proper fix needs

A label-content-only heuristic isn't sufficient. A correct fix needs document-level context, e.g.:

• Detect a corresponding [clear]: <url> reference definition elsewhere in the input. If present, the bracket-pair is unambiguously a markdown reference link.
• Or product input: clarify whether [emotion-word][emotion-word] at line start should always strip as emotion tags (current behavior), or whether reference-link semantics should win.

Suggested next steps:

1. Decide the desired behavior for [emotion-word][emotion-word] at line start when no reference definition exists in the document — strip-as-emotion (current) or preserve-as-reference (Copilot's preferred).
2. If preserving, parse the input for ^\[([^\]\n]+)\]:\s definitions and gate reference-link classification on a definition existing for the second label.
3. Add bidirectional test coverage: line-start emotion-pair stays stripped; line-start [fast][1] (no definition) preserves; [fast][clear] with [clear]: … definition preserves; [fast][clear] without definition strips.

Scope of impact

Any chat-history or live-stream text that uses markdown reference-link syntax at the start of a line is at risk. The narrow practical impact today is the [fast][1] example surviving as [1] in off/on modes — unlikely to corrupt critical content, but visibly wrong on any docs/markdown-rich assistant output.

Discovered

PR review on #72229 / #72266. Inline comment placed at src/shared/text/emotion-tags.ts line 211-220 in commit f59cde0a6f documenting the ambiguity. Threads on both PRs left open with a pointer to this issue.