fix: surface individual settings like "Color Filters" in search (#471)#476
fix: surface individual settings like "Color Filters" in search (#471)#476shobhit99 wants to merge 4 commits into
Conversation
System Settings panes exposed only the top-level pane (e.g. "Accessibility"), so sub-settings findable in Spotlight — like "Color Filters" — could not be found in SuperCmd. discoverSettingsSearchTermCommands() already parsed each pane's .searchTerms file to extract these sub-settings, but it was never called. Wire it into the appex (Source 1) discovery loop so every pane's individual settings are added to the command list, searchable by name and keyword just like in Spotlight. Also bump COMMANDS_DISK_CACHE_VERSION to 2 so existing installs refresh their cached command list to include the new sub-settings on first launch. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Codex review (P2): discoverSettingsSearchTermCommands added each top-level .searchTerms key as its own visible command. Those keys are internal identifiers (e.g. "AX_ALT_MOUSE_ENABLE_SOUNDS"), so wiring the function in flooded the launcher with ~300+ junk commands per pane. Every key carries the real human label in localizableStrings[].title (verified: across 47 system panes, only 2 keys lack rows). Drop the section-key-as-title branch and its identifier-derived keywords; emit only row titles plus their curated `index` keywords. Accessibility sub-items drop 679 -> 342 clean entries; "Color Filters" still resolves. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Codex review (gpt, reasoning=high) — GATE: PASSOne [P2] finding, now fixed in
Verified and fixed:
No other findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 009889261a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| searchTermsFileName | ||
| ); | ||
|
|
||
| return [paneCommand, ...subItems]; |
There was a problem hiding this comment.
When this new path appends every result returned by discoverSettingsSearchTermCommands, it also exposes the helper's section-level commands. For .searchTerms files whose top-level keys are internal identifiers (for example the Color Filters entry is keyed by AX_DISPLAY_FILTER_ENABLED), the helper adds that key as a command before adding the localized row title, and cleanPaneName does not remove underscores, so users will see bogus commands like AX_DISPLAY_FILTER_ENABLED alongside the intended Color filters result. Consider only appending row-derived titles or filtering section keys that look like identifiers.
Useful? React with 👍 / 👎.
…results Wiring in per-setting search (previous commits) meant a query could surface hundreds of granular toggles competing with apps, commands, and panes — the launcher root is a curated namespace, not an exhaustive index like Spotlight. Mark each setting sub-item (CommandInfo.settingsSubItem) and treat it as a low-priority fallback in both ranking paths: - Root-search path (useLauncherCommandModel): skip sub-items for queries under 3 chars; apply a noise penalty (200) so they sort below real results. Weak (contains/subsequence) sub-item matches fall under the promotion floor and drop out entirely; strong (exact/prefix) ones still appear, lower down. - Legacy filterCommands path: same 3-char gate, and hard-tier sub-items below all non-sub-item matches regardless of raw score. Net: "color filters" still finds Color Filters, but typing "co" no longer floods results with accessibility toggles, and sub-items never outrank the app or command you actually wanted. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Three findings from an independent review of the fallback-ranking change: - P2 (exact sub-item leapfrog): compareRootSearchCandidates ranks exact matches before finalScore, so an exactly-named settings sub-item could still jump above a fuzzily-matched real command despite the noise penalty. Add a strict fallback tier in the comparator — settings sub-items always sort below any other internal result. Placed after the organic-browser partition (keeping "internal beats browser") and before the exact/intent tiers; it's a clean binary partition so the comparator stays transitive. This also unifies the root-search path with the legacy filterCommands hard-tier. - P2 (settings tab flood): the Settings -> Extensions "System Settings" group listed every settings command, so the sub-items now flood that management UI. Exclude settingsSubItem entries from both the lookup map and the displayed list — only top-level panes are assignable there. - Add regression tests: a sub-item ranks below a real command even on an exact match, and a weak (subsequence) sub-item match is dropped below the promotion floor while a strong (exact) one is promoted. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
1 participant
Summary
Fixes #471 — settings findable in Spotlight (like Color Filters) couldn't be found in SuperCmd.
System Settings discovery only added the top-level pane (e.g. "Accessibility") to the command list. macOS exposes each pane's individual settings in a
.searchTermsplist inside the settings bundle, and SuperCmd already had a function to parse it —discoverSettingsSearchTermCommands()— but it was never called. It was effectively dead code.This PR wires that function into the appex (Ventura+) settings discovery loop, so each pane's individual settings are added to the searchable command list, by name and keyword, just like Spotlight.
Example: "Color Filters" lives in the Accessibility bundle's
UniversalAccess.searchTermsasAX_DISPLAY_FILTER_ENABLED→ title"Color filters", keywordsenable color filters, color blind, colorblind. After this change, searching "color filters" returns it, opening to Accessibility settings.Changes
src/main/commands.ts: calldiscoverSettingsSearchTermCommands()for each discovered appex pane and append the resulting sub-settings to the command list.COMMANDS_DISK_CACHE_VERSION1 → 2 so existing installs refresh their cached command list and pick up the new sub-settings on first launch.Each sub-item carries the parent pane's icon and a subtitle of the pane name, reuses the pane's open identifier (selecting it opens the parent pane), and is excluded from the generic-icon dedup pass because it has a subtitle.
Test Coverage
The discovery path reads live macOS system bundles and the helper is internal (not exported), so it isn't covered by the existing pure-function test suite. Verified manually:
AccessibilitySettingsExtension.appex/.../UniversalAccess.searchTerms— "Color filters" is produced with the expected title and keywords.npm test— 27/27 pass (root-search ranking suite).npm run check:i18n— all locales OK (no user-facing strings changed; sub-setting titles come from macOS).npm run build:main— clean.Test plan
🤖 Generated with Claude Code