test(CommandPalette): drive real fuse.js at the mark-insertion boundary

[arsalan507]

Linked issue

Refs #362.

Type of change

• Documentation (updates to the documentation or readme)
• Bug fix (a non-breaking change that fixes an issue)
• Enhancement (improving an existing functionality)
• New feature (a non-breaking change that adds functionality)
• Chore (updates to the build process or auxiliary tools and libraries)
• Breaking change (fix or feature that would cause existing functionality to change)

Tests only — src/ untouched.

Description

#371 covers the mark-insertion boundary more completely than my #379 did — the ordering, the nested-region and non-integer guards, and the grapheme snap all go beyond what was there.

One gap is left, and it is the piece #379 was built around: every astral fixture in mark insertion is a recorded copy of fuse output. A recording cannot notice when a fuse upgrade stops producing those offsets — the fixture stops straddling a character and the test goes on passing without exercising the boundary at all.

This searches with the real library at the options ContentSearch ships and asserts the offsets before asserting the output, so that upgrade fails here loudly instead.

Verified failing against a build with cluster snapping disabled. test/utils/ and test/components/CommandPalette.spec.ts green; eslint and vue-tsc --noEmit clean.

Happy to fold it into an existing case instead if you would rather not add a fuse import to this spec.

Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.

[IgorShevchik]

Thanks for splitting this out, and for closing #379 the way you did.

You're right about the gap. Every astral fixture in mark insertion is recorded fuse output, so an upgrade that stopped producing those offsets would leave the test passing without ever exercising the boundary — asserting the indices before the output is what makes that fail loudly instead. That is worth having.

Sorry #379 got run over by #371 landing in parallel. The aim was closing #362 quickly, not discarding your work, and I should have said so here sooner.

We'll review this properly tomorrow.

One thing from your #379 worth passing back, since it is genuinely interesting rather than a complaint. Running your test block against current main, 13 of 15 cases pass unchanged. One of the two that doesn't is snaps both boundaries when each lands inside 🏿:

main:      "a<mark>b🏿cd🏿</mark>ef"
#379:      "ab<mark>🏿cd🏿</mark>ef"

U+1F3FF has Grapheme_Cluster_Break = Extend, and UAX #29 rule GB9 (× Extend) forbids a break before it whatever precedes it — so "b🏿" is a single cluster and the mark cannot open inside it:

"ab🏿cd🏿ef" → "a"@0  "b🏿"@1  "c"@4  "d🏿"@5  "e"@8  "f"@9

The fixture came from the range-edge set in #365, where it reads as an ordinary astral character. It isn't one. Same trap caught us on our side too.

The other difference is the single-character skip measured in code points rather than code units. You're right that the current rule is inconsistent, and we're taking that fix — it'll credit #379.

---

Generated by Claude Code

[IgorShevchik]

Reviewed properly. I said "tomorrow" and it has been two days — sorry, that was my slip, and it is the second time your work in this file has waited on mine.

Updating for you rather than asking: the base had moved 21 commits, since #388, #390 and #405 all landed in search.ts and its spec meanwhile. It merges clean in both directions — no conflict with any of them.

What I checked

Your argument is that the eight astral fixtures in mark insertion are recorded copies of fuse output, so a fuse upgrade that changed those offsets would leave them passing while no longer straddling anything. I went looking for whether anything else in the suite would notice. Nothing does:

$ grep -n "indices).toEqual" test/utils/search.spec.ts test/components/CommandPalette.spec.ts
test/utils/search.spec.ts:302   expect(matches?.[0]?.indices).toEqual([[0, 11], [13, 13]])

That line is yours. It is the only assertion in the repository about what fuse actually returns. describe('highlighting through fuse') in CommandPalette.spec.ts does drive the real library, but it asserts on rendered HTML — it would only notice a fuse change that happened to alter visible output, which is a weaker guarantee than the one you are adding.

Mutation-checked it too: disabling the cluster snap fails your test along with 22 others, so it is not uniquely pinning that. The uniqueness is the offsets, which is what the test says on the tin.

On the wider trade

Pinning a dependency's exact output does mean a benign fuse upgrade can turn this red. That is the cost, and I think you have it the right way round — a loud failure that says "the fixture no longer straddles" is worth more than eight tests quietly measuring nothing. The test's name carries that reasoning, so whoever hits it will know what it is telling them.

No changes requested. Merging as soon as CI is green.

Where the rest of your work went

Since it touched the same code: the single-character skip you moved to code points in #379 is still an open question rather than a silent drop — it is #392, along with a second behaviour the same review turned up. And the review pass over search.ts that your PRs kicked off has since found four more defects in it (#387, #391, #410, #411), two of them shipped since the original port. Your two PRs are what started that.

Thanks for the patience, and for splitting this out instead of letting it go down with #379.

---

Generated by Claude Code