feat: add support for @ to do file search

[bolinfest]

Introduces support for @ to trigger a fuzzy-filename search in the composer. Under the hood, this leverages https://crates.io/crates/nucleo-matcher to do the fuzzy matching and https://crates.io/crates/ignore to build up the list of file candidates (so that it respects .gitignore).

For simplicity (at least for now), we do not do any caching between searches like VS Code does for its file search:

https://github.com/microsoft/vscode/blob/1d89ed699b2e924d418c856318a3e12bca67ff3a/src/vs/workbench/services/search/node/rawSearchService.ts#L212-L218

Because we do not do any caching, I saw queries take up to three seconds on large repositories with hundreds of thousands of files. To that end, we do not perform searches synchronously on each keystroke, but instead dispatch an event to do the search on a background thread that asynchronously reports back to the UI when the results are available. This is largely handled by the FileSearchManager introduced in this PR, which also has logic for debouncing requests so there is at most one search in flight at a time.

While we could potentially polish and tune this feature further, it may already be overengineered for how it will be used, in practice, so we can improve things going forward if it turns out that this is not "good enough" in the wild.

Note this feature does not work like @ in the TypeScript CLI, which was more like directory-based tab completion. In the Rust CLI, @ triggers a full-repo fuzzy-filename search.

Fixes #1261.

[bolinfest]

Currently, this feels good for small repos, but is jarring for large repos because the user cannot type while task::block_in_place(|| handle.block_on(future)) is running.

[github-actions]

Summary

Adds @-triggered file-search to the TUI: the composer detects @token, shows a live popup with matching paths, and lets users insert a selection. Implementation introduces FileSearchManager, FileSearchPopup, new AppEvents, and wires them through ChatComposer, BottomPane, and App.

Review

Great UX improvement and the code plugs into existing architecture cleanly. A few small thoughts:

• Concurrency: FileSearchManager spins a new thread (plus a 20 ms busy-poll) per search; consider a channel/worker to avoid potential thread growth and polling.
• current_at_token/insert_selected_path index by byte; non-ASCII filenames might misbehave—worth documenting or switching to char_indices.
• Might be nice to unit-test the debounce/cancel logic and token parsing.
• Nit: MAX_RESULTS/NUM_FILE_SEARCH_THREADS could live in Config for tunability.

Overall, solid feature—just minor polish opportunities.

---

View workflow run