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

["faga295 (via GitHub)" <gi...@apache.org>]

GitHub user faga295 created a discussion: Ranking for @ file search — weighted score vs. categories, plus recent-usage history


   ## 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:

   ```ts
   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?

GitHub link: https://github.com/apache/maka/discussions/4851

----
This is an automatically sent email for dev@maka.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@maka.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maka.apache.org
For additional commands, e-mail: dev-help@maka.apache.org