Resume does not restore the selected list item (cursor) position

[KorigamiK]

Description

When resuming a picker (resume, resume_find_files, resume_live_grep), the previously selected list entry is not restored — the selection always jumps back to the first result, even though the query, results, and scroll state are otherwise restored.

Steps to reproduce

1. Open the file picker and type a query that returns several results.
2. Move the selection down a few entries (so the highlighted item is not the first one).
3. Close the picker (with a non-empty query, so state is snapshotted).
4. Resume the picker.

Expected: the same list item is highlighted as when the picker was closed.
Actual: the selection resets to the first result.

Root cause

restore_from_state (lua/fff/picker_ui/picker_ui.lua) restores state.cursor correctly, but then writes the saved query into the input buffer. The input buffer's on_lines callback (ui_creator.lua) schedules on_input_change, which re-runs the search via update_results_sync and unconditionally sets S.cursor = 1 (search_manager.lua), discarding the restored cursor.

Environment

• fff.nvim: latest main
• Neovim: any recent version

[gustav-fff]

[triage-bot] LINKED PR:

Linked PR #613 (open): #613

Adds a one-shot suppress_input_change flag in restore_from_state so writing the saved query into the input buffer does not trigger on_input_change, which would re-run the search and reset S.cursor = 1. Snapshot already holds items/filtered_items/cursor, so skipping the re-search preserves the restored cursor and renders once. Awaiting maintainer review.

Honk-Honk 🪿

[dmtrKovalenko]

this is done this way cause we can't guarantee that the results are in the same order since the last open

[KorigamiK]

this is done this way cause we can't guarantee that the results are in the same order since the last open

Ah, we'll this is interesting, because i'd like to keep the re-search and be able to resume. I've updated the PR to now keep the search running on resume and only carries the cursor across (clamped to the fresh results, falling back to the top if the row no longer exists), so stale ordering is never assumed.