Repository navigation
fix(search): snap snippet boundaries to whole words - #15
Open
ashishbhateja wants to merge 1 commit into
Open
ashishbhateja wants to merge 1 commit into
ashishbhateja wants to merge 1 commit into
Conversation
The snippet() window was centred on the start of the first matched term and sliced at arbitrary character positions, producing fragments like "… refixword search endwo …" when rawStart or rawEnd fell mid-word. Now, when a boundary lands inside a word: - rawStart: advance to after the next space (next word start) - rawEnd: retreat to the preceding space (end of previous word) A guard on the end snap (prevSpace > idx) ensures we never retreat past the start of the matched term itself, even when the context window is very tight. Two smoke tests assert the new behaviour: one per boundary direction. Advances issue #3 (search result display quality).
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The
snippet()function insrc/search.jscentred its context window on the first matched term and then sliced the text at arbitrary character positions. WhenrawStartorrawEndfell mid-word, the result was fragments like:After this fix:
How
Two small adjustments to the boundary calculation, applied only when the boundary is not already at the edge of the text:
rawStartmid-word → advance to after the next space (nextSpace + 1), so the snippet begins at a whole word.rawEndmid-word → retreat to the preceding space, so the snippet ends at a whole word.A guard on the end adjustment (
prevSpace > idx) ensures we never retreat past the start of the matched term, even with a very tightcontextCharssetting.The fallback path (no match found — returns the start of the text) is unchanged.
Tests
Two new smoke tests added to
scripts/smoke.mjs:snippet snaps start boundary to a whole word— rawStart inside'longprefixword', verifies snippet begins with a whole token.snippet snaps end boundary to a whole word— rawEnd inside'endword', verifies snippet ends with a whole token.All 21 checks pass (
npm test);npm run buildsucceeds.Issue
Advances #3 — improves the display quality of search result snippets shown in the reading list.
Generated by Claude Code