Picker: cursor resets to top after in-place removal (alt-r)

[max-sixty]

The interactive picker's in-place removal (alt-r) works correctly — the worktree is removed and the item disappears from the list — but the cursor resets to the first item after each removal. This is disruptive when removing multiple worktrees in sequence.

Root cause

Skim 0.20's reload action calls clear_selection() before restarting the matcher. Even though our CommandCollector streams the updated items immediately via an unbounded channel, the selection is already cleared by the time items reach the pool.

The fix exists in skim 4.0: Action::Custom(ActionCallback) gives &mut App access to manipulate item_list directly without going through reload, which would preserve cursor position.

Why we can't upgrade yet

Skim 4.0 uses exact version pins (=x.y.z) on all ~30 dependencies, making it unusable as a library dependency. Every transitive dependency must match exactly, creating cascade conflicts:

• memchr = "=2.8.0" vs our transitive memchr 2.7.6
• futures = "=0.3.32" vs our transitive futures-core 0.3.31
• tempfile = "=3.26.0" vs our tempfile = "^3.27"
• ~27 more exact pins with the same problem

Filed upstream: skim-rs/skim#989 (related — build failures from pinning)

Current behavior

After pressing alt-r, the selected worktree is removed and the list updates, but cursor jumps to position 0 (first item). The user must navigate back to where they were.

Desired behavior

Cursor stays at the same position (or moves to the adjacent item if the removed item was at the cursor).

Workaround

None currently. Users can still remove multiple worktrees, just with extra navigation after each removal.

This was written by Claude Code on behalf of @max-sixty

[worktrunk-bot]

Thanks for the detailed write-up! I can confirm this is a known limitation — it's already documented in the codebase (src/commands/picker/mod.rs lines 56-60):

Cursor position resets to the first item after reload. This is a skim 0.20 limitation: act_reload clears the selection, then restart_matcher races the reader thread — if items aren't in the pool yet, the empty matcher result clamps line_cursor to 0. The fix is skim 4.0's Action::Custom(ActionCallback) which gives &mut App access to manipulate item_list directly without reload.

The root cause is upstream in skim 0.20 — there's no workaround available in our code. The fix path is upgrading to skim 4.0 once the exact-pin dependency issue (skim-rs/skim#989) is resolved.

I'll leave this for a maintainer to track and prioritize.