GemStone Search: rank the selector scan, reset on a session switch, add a refresh

[ericwinger]

Closes #517. Three defects in GemStone Search, all of them the panel answering out of state that is no longer true.

1. Typing at: never returned Array>>at:

The Methods scope asks the stone for a bounded number of matching selectors so searching-as-you-type stays fast. The stone collected the first limit matches it walked into — dictionary-hash order, nothing to do with relevance. Measured on a 3.6.2 base image: 1142 selectors contain at: and only 31 are at:, so with a slice of 80 the exact implementors sat far past the cutoff and were never sent. The slice filled with instVarAt:put: and floatAt:put: from a couple of incidental classes.

buildSelectorSearchCode now sorts matches into tiers — the selector is the term, starts with it, merely contains it — and returns them best-first, each tier capped. What a cut-off drops is now the least relevant tail. The walk no longer short-circuits on a match count (a better-tier hit can be anywhere in the image); the one early exit left is a full exact tier, where nothing later can displace a row. Cost for at:: ~27 ms against ~2 ms — and a full walk was already the price of every precise term, which never reached the old cutoff at all.

One trap worth knowing about if you touch that query. GciLibrary.execute compiles our source with Utf8 as its string class, so every literal in it is a Utf8 while sel asString answers a String. Comparing the two raises ArgumentError 2718, Unicode argument disallowed in String comparison and takes the whole search down. The tier test therefore uses integer sizes plus includesString: and no string = anywhere; a unit test guards against a "clearer" rewrite. The live-stone integration test caught this — the unit tests could not.

2. Making another session active did nothing to the search

The docked panel rebuilt its engine only when something else happened to ask it to (a reveal, a settings change, the next keystroke); an open Spotter never rebuilt at all. Until then both kept answering — and opening rows — out of the session the user had left.

Both hosts now listen to SessionManager.onDidChangeSelection. Two decisions worth recording:

• The webview is wiped, not just the engine. Dropping the engine is enough for a settings change, because the rows on screen are still true. Here they are not: they came from the old session, they still look live, and activating one would open a document against the session that is now current.
• The wipe is not deferred while hidden, though the re-prime still is. The visible gate exists to keep image-wide GCI executes off a background path, and that still holds for re-priming. It does not hold for clearing the screen: a reveal cannot un-show stale rows.

The Spotter is re-pointed in place rather than closed and reopened — it is an editor tab the user put there, possibly pinned, and the tab, its pin and its HTML are all session-independent. show() for a different session takes the same path, which replaced its old dispose-and-recreate branch. Logging out of the last session is the same event with nothing to bind to: both hosts reset and say Log in to a GemStone session to search.

3. Nothing could pick up code created by executing it

A subclass: evaluated in a workspace, a method compiled by a compileMethod: doit, a global assigned in a doit — none of them announce anything the panel can listen for, so short of a commit or abort the cached class/dictionary/global/category corpora stayed stale with no upper bound.

A ⟳ in the search bar (both surfaces), in the panel title bar, and gemstone.search.refresh in the palette reloads every corpus and re-runs the current term. It ignores the visibility gate the sync hooks use — the user asked for it now — and clears any deferred sync so one click is one walk.

It is a separate engine call (refresh) rather than the button wired to resync, and the difference is the pivot: resync deliberately leaves a references list alone, which made the ⟳ a dead button for anyone reading one. refresh re-asks the stone who references the row the pivot was taken from, keeps whatever filter is typed into it, and leaves the pivot if that row has been deleted.

Also fixed, found while testing: collapsing the panel disposes the view, and the fresh webview a reopen creates was never sent its config message (empty tab row, zero debounce until the first search refilled it).

Testing

npm test green: 6641 client + 322 server + 92 mcp. New coverage:

• methodsRelevance.integration.test.ts — live stone, both releases: the bounded scan returns the exact implementors of at: including Array>>at:, they lead the slice, and a substring-only term still comes through (the tiers rank, they must not filter).
• searchSelectors.test.ts — tier caps, best-first order, the exact-tier-only early exit, and the no-string-= guard.
• omniSearchViewProvider.test.ts — session switch wipes + rebinds (visible and hidden), no-op on re-selecting the same session, logout resets, refresh reloads once when a hidden sync was also owed, refresh builds nothing for a view never instantiated, config re-sent on reopen.
• omniSearchPanel.test.ts — the Spotter rebinds in place, ignores a re-selection of its own session, resets on logout, and builds nothing when closed.
• omniEngine.test.ts — refresh vs resync over a pivot, pivot filter preserved across a re-fetch, pivot left when its target is gone.
• omniRefreshAndReset.test.ts — the ⟳ posts refresh and keeps the typed term; reset clears query, rows, preview, breadcrumb, error, references chip, and returns the scope to All.

Manually verified on a live 3.7.5 stone against a fixture (a class with exact/prefix targets plus 250 substring decoys, above the server ceiling): ranking A1–A5, refresh B1–B6, session switching C1–C5, and no-regression checks D1–D5.

🤖 Generated with Claude Code