Smarter search

[rumpl]

In the command palette typing "the" will now put "Theme" first on the list, and typing "ses" will put "Sessions" first on the list

[docker-agent]

Assessment: 🔴 CRITICAL

The new test TestCommandPaletteFilteringRanksLabelPrefixFirst has a broken assertion — it expects session.attach to appear in filtered results for query "the", but none of that command's fields (label, slash command, or description) contain the substring "the". The test will fail as written.

[docker-agent]

[HIGH] Test assertion incorrectly expects session.attach to appear for query "the"

The test TestCommandPaletteFilteringRanksLabelPrefixFirst queries for "the" and asserts []string{"settings.theme", "session.attach"}, but session.attach has:

• Label: "Attach" → lowercase "attach" — does not contain "the"
• SlashCommand: "/attach" — does not contain "the"
• Description: "Attach a file to your message" — does not contain "the"

All four commandFieldQueryScore calls return commandQueryNoMatch, so session.attach is filtered out entirely. The actual filtered result would be ["settings.theme"] only, causing require.Equal to fail.

The intent of the test appears to be verifying that a label prefix match ranks ahead of a substring match. A suitable second command would be one whose description or label contains "the" as a mid-word substring (e.g., a command with description containing "the") to demonstrate that settings.theme (label prefix) ranks first.

[docker-agent]

[LOW] isCommandQueryWordStart uses byte indexing; non-ASCII characters before the match position are not recognized as word boundaries

value[index-1] reads one byte before the match (where index is a byte offset from strings.Index). If the preceding character is a multi-byte UTF-8 sequence (e.g., é, ñ, or CJK), index-1 lands inside that sequence and reads a continuation byte (0x80–0xBF), which never equals any ASCII word-separator. This means a non-ASCII character immediately before the query match is never classified as a word boundary, slightly degrading ranking for non-ASCII content.

For the current use case (ASCII command names and descriptions) this has no practical impact. Consider using utf8.DecodeLastRuneInString(value[:index]) if internationalized command labels are ever needed.