adrianlopezroche
commented
1 month ago I think it needs three constraints:
- No backtracking: On the assumption that sets appearing before the cursor have already been reviewed by the user, don't move the cursor to an earlier set if it can be avoided.
- No skipping: On the assumption that sets appearing after the cursor have not yet been reviewed by the user, don't move the cursor past the current set (or its nearest successor if the current set is delisted).
- No going out of bounds: If after following the last two rules the cursor should fall out of bounds, move the cursor back to the last set (as currently implemented).
I'll have to review the interactive deletion code (which, frankly, is a bit of a mess), but I think this would work.
After pruning selected dupe-sets (as per man fdupes-help, deleting duplicates section), current set under the cursor seems off.
For instance, I've selected sets 1 to 72 out of 1072 sets (keeping one file for each), then pressed the delete key. Files marked for deletion are dealt with and, since those sets had a file tagged for keeping, thoses sets are delisted. Now, I have 1000 sets to review and current set is… 73rd (of 1000). I guess it is due to the fact that, prior to pruning, I was pointing at set 73 (of 1072). I would expect the "current set index" to be decremented by the number of sets delisted.
The logic can't be all that simple, though: it's ok even if sets to be delisted aren't contiguous, but not if the current set index (prior to pruning) is lower than the number of sets to be delisted (e.g. selecting sets 2 and 3, moving back to set 1, pruning -> if implemented naïvely, current set would now be –1, i.e. out of bounds). Also, currently, what happens if one selects/prunes/delists sets 1 to 6 out of 10? Can't have a set index pointing at set 7 of 4.¹
One could argue for resetting the current set index to 1 after each prune operation. However, had I left some sets undetermined, I'd rather keep going after those, once the partial pruning were done. (It's now getting a bit too tricky for what I can think off the top of my head.)
(1) Edit: currently, the index seems to be bound by the set list size. In my example, after pruning, the last set available is the current one.