Skip to content

@ picker with empty query lists alphabetical index head instead of recently modified files #6651

Description

@bug-ops

Description

When the @ picker opens with an empty query, it shows the first 10 paths of the sorted file index (FilePickerState::refilter, crates/zeph-tui/src/file_picker.rs:155-195 — empty query → head of the alphabetically sorted index). In any real repository that is a nearly useless slice (e.g. .cargo/config.toml, .github/...), so the empty-query state wastes the picker's most valuable moment — the instant it opens, before the user types anything.

Expected Behavior

With an empty query, the picker lists the files the user is most likely to mention, in order:

  1. Files with uncommitted modifications (git status --porcelain, staged + unstaged + untracked-but-not-ignored), most recently modified first.
  2. Then recently modified tracked files (mtime descending) up to the visible limit.

Once the user types a query, ranking is fully delegated to the fuzzy matcher (status quo) — this issue changes the empty-query ordering only.

Implementation Notes

  • The git-status/mtime pass can piggyback on the existing background FileIndex::build (already offloaded via the task supervisor / spawn_blocking; index TTL 30 s) — store an ordering hint alongside the path list instead of shelling out on every popup open.
  • Non-git directories degrade to mtime-only ordering; failures degrade silently to the current alphabetical head (never block or error the picker).
  • Applies per category tab: this ordering concerns the Files category; Skills/Agents empty-query ordering (alphabetical) is unaffected.

Environment

  • Version: main @ v0.22.3
  • Crate: zeph-tui

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3Research — medium-high complexityenhancementNew feature or requesttuiTUI dashboarduxUser experience

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions