Ranking for @ file search — weighted score vs. categories, plus recent-usage history

[faga295]

Current state

The composer's @ file search (apps/desktop/src/main/workspace-file-search.ts) currently matches and ranks as follows:

1. Filtering: substring match on the query, case-insensitive. The @ trigger ends at a space, so the query is effectively a single token (no multi-token).
2. Ranking: path length ascending + lexicographic only:

filtered.sort((a, b) => a.length - b.length || a.localeCompare(b));

Problem

Path length correlates poorly with relevance:

• For config, src/config/foo.ts (a directory-only hit) can rank above myconfig.ts (a filename substring hit) or even packages/settings/config.ts (an exact filename hit) simply because its path is shorter —
  shorter path ≠ better match.
• There is no "recently used" signal at all: frequently opened files never float to the top, so the right file has to be hunted down every time.

Proposal

Two possible ranking mechanisms (and, in either case, a recent-usage history).

Option A: Weighted score

Compute a combined weight for each candidate by summing several dimensions:

• Match position: exact filename > prefix > word boundary > extension > path-segment prefix > filename substring > path substring > fuzzy, each level carrying a numeric weight
• Refinements: match start position, full coverage of the filename core, fuzzy compactness
• Penalties: path depth, overly long filenames, generated / build-output directories
• Recent usage: recency + frequency

Sort by total score, descending.

Pros: captures fine differences within the same level (e.g. among "substring" hits, a prefix-at-start beats a mid-string hit, and compactness is distinguishable).
Cons: numeric values need tuning; behavior is less intuitive; cross-level overrides need explicit constraints.

Option B: Categories (discrete tiers, fixed priority)

Classify each hit into one of a few tiers and rank by a fixed priority:

exact match > recently used > prefix match > word boundary > contains > fuzzy

• An exact filename match always wins;
• next come recently used files (recency + frequency, regardless of which match tier they fall into);
• then the remaining match tiers: prefix > word boundary > contains > fuzzy;
• ties within a tier break by path length + lexicographic order.

Pros: simple, intuitive, predictable, easy to debug and explain (each result's position has a clear reason).
Cons: the tier granularity caps the outcome; finer relevance differences within a tier can't be expressed.

What the two options share

• "Recently used" (recency + frequency) fits both: as a weight dimension in Option A, or as a priority level right after "exact match" in Option B.
• Both replace the current "path length" ranking.

Open questions

1. Go with A (weighted), B (categories), or a hybrid of "category tiers + weighted score within a tier"?
2. Should we persist "recently used" for ranking? (storage location, per-project vs. global, file format)
3. Fuzzy subsequence matching would surface files that can't be found today — do we want it? And do we need a minimum-score threshold to filter weak hits?