Two follow-ups that came out of reviewing #240 (class-search ranking) against what GemStone Search (#378) actually shipped.
The ranking #240 asked for is already in place — client/src/omniSearch/omniMatch.ts puts an exact match first, then prefix matches shortest-first, then mid-name matches. Running the real matcher over the class names containing Object, case-insensitive, default fuzzy mode:
1 Object score 44
2 ObjectLog score 41
3 ObjectStub score 41
4 ObjectAudit score 40
5 ObjectHandle score 40
6 ObjectHistory score 40
7 ObjectLogEntry score 39
8 ObjectFilterSet score 39
9 ObjectSecurityPolicy score 38
10 BadObjectError score 35
11 RcObjectHolder score 35
12 SmallObjectStub score 35
13 GsObjectInventory score 35
14 PersistentObjectCache score 34
15 GsObjectSecurityPolicy score 34
16 AbstractObjectSerializer score 34
But that ranking is not what you get from the command whose name says it finds classes. Hence the two items below.
1. Retire Find Class… and route Ctrl+K C to GemStone Search
gemstone.findClass (client/src/extension.ts:2613) is a bare vscode.window.showQuickPick over loadClassPickItems with matchOnDescription: true. It never calls omniMatch, so its result order is whatever VS Code's built-in filter produces — the behaviour #240 was filed about. Two other problems with the same command:
- It re-runs the image-wide
getAllClassNames behind a modal Loading class list… progress on every invocation. The GemStone Search Classes provider primes that corpus once and keeps it fresh incrementally (applyChange on compile/remove, reprime on session sync). client/src/omniSearch/providers/classesProvider.ts notes it reuses "the same getAllClassNames corpus Find Class uses" — same data, only one of the two ranks it well.
- Having two class-search entry points means the one with the more obvious name and the older keybinding is the worse experience, which is how a new user finds it first.
Fixing the QuickPick in place is not really available: VS Code always applies its own filter to QuickPick.items, so handing it a pre-ranked list does not preserve the order. The clean fix is to point Ctrl+K C (and the GemStone: Find Class… palette entry) at gemstone.search with the Classes scope preselected, and delete the standalone picker. Same reasoning as #421 — collapse to one discovered default.
Scope:
gemstone.search needs to accept a preselected scope so the redirect lands on Classes rather than the full fan-out.- Remove
gemstone.findClass, its keybinding, its palette entry, and loadClassPickItems if findMethodInClass no longer needs it (it currently shares it — client/src/commands/findMethodInClass.ts). Decide separately whether Find Method in Class (Ctrl+K M) gets the same treatment; it is a different interaction (class first, then its selectors) and may be worth keeping as a QuickPick.
- Sweep the prose:
README, the Get Started walkthrough, and any doc or comment that still tells the user to use Find Class….
2. Add an exact match mode
MatchMode is 'fuzzy' | 'substring' | 'prefix' (client/src/omniSearch/omniMatch.ts), surfaced as the click-to-cycle button in the search panel header and the gemstone.omniSearch.matchMode setting. Reading those as wildcard patterns, that covers *q*, q* and the subsequence feel — but not q with no wildcards at all, i.e. "the name is exactly what I typed".
A matchExact arm plus one enum entry in package.json (with its enumDescriptions string) and one more label in the panel's cycle order. Cheap, and it completes the set the discussion on #240 asked for.
Note on sort order, for the record
The ranking above sorts by score, then target length, then alphabetically (compareMatches). That means length beats alphabetical — alphabetical is only the third tiebreaker. The #240 discussion floated alphabetical-with-exact-match-on-top as an alternative; the shipped behaviour went the other way. Flagging it because it was a real fork in the road, not an oversight. If it should change, that is a one-line change in compareMatches and a handful of test expectations.
Related
Two follow-ups that came out of reviewing #240 (class-search ranking) against what GemStone Search (#378) actually shipped.
The ranking #240 asked for is already in place —
client/src/omniSearch/omniMatch.tsputs an exact match first, then prefix matches shortest-first, then mid-name matches. Running the real matcher over the class names containingObject, case-insensitive, defaultfuzzymode:But that ranking is not what you get from the command whose name says it finds classes. Hence the two items below.
1. Retire
Find Class…and routeCtrl+K Cto GemStone Searchgemstone.findClass(client/src/extension.ts:2613) is a barevscode.window.showQuickPickoverloadClassPickItemswithmatchOnDescription: true. It never callsomniMatch, so its result order is whatever VS Code's built-in filter produces — the behaviour #240 was filed about. Two other problems with the same command:getAllClassNamesbehind a modalLoading class list…progress on every invocation. The GemStone Search Classes provider primes that corpus once and keeps it fresh incrementally (applyChangeon compile/remove,reprimeon session sync).client/src/omniSearch/providers/classesProvider.tsnotes it reuses "the samegetAllClassNamescorpusFind Classuses" — same data, only one of the two ranks it well.Fixing the QuickPick in place is not really available: VS Code always applies its own filter to
QuickPick.items, so handing it a pre-ranked list does not preserve the order. The clean fix is to pointCtrl+K C(and theGemStone: Find Class…palette entry) atgemstone.searchwith the Classes scope preselected, and delete the standalone picker. Same reasoning as #421 — collapse to one discovered default.Scope:
gemstone.searchneeds to accept a preselected scope so the redirect lands on Classes rather than the full fan-out.gemstone.findClass, its keybinding, its palette entry, andloadClassPickItemsiffindMethodInClassno longer needs it (it currently shares it —client/src/commands/findMethodInClass.ts). Decide separately whetherFind Method in Class(Ctrl+K M) gets the same treatment; it is a different interaction (class first, then its selectors) and may be worth keeping as a QuickPick.README, the Get Started walkthrough, and any doc or comment that still tells the user to useFind Class….2. Add an
exactmatch modeMatchModeis'fuzzy' | 'substring' | 'prefix'(client/src/omniSearch/omniMatch.ts), surfaced as the click-to-cycle button in the search panel header and thegemstone.omniSearch.matchModesetting. Reading those as wildcard patterns, that covers*q*,q*and the subsequence feel — but notqwith no wildcards at all, i.e. "the name is exactly what I typed".A
matchExactarm plus one enum entry inpackage.json(with itsenumDescriptionsstring) and one more label in the panel's cycle order. Cheap, and it completes the set the discussion on #240 asked for.Note on sort order, for the record
The ranking above sorts by score, then target length, then alphabetically (
compareMatches). That means length beats alphabetical — alphabetical is only the third tiebreaker. The #240 discussion floated alphabetical-with-exact-match-on-top as an alternative; the shipped behaviour went the other way. Flagging it because it was a real fork in the road, not an oversight. If it should change, that is a one-line change incompareMatchesand a handful of test expectations.Related