jesseduffield
Deleting multiple items should reset selection mode
Describe the bug
When selecting multiple commits and deleting them, selection mode stays enabled.
To Reproduce Steps to reproduce the behavior:
- Hit
vin the commit log. - Select multiple commits.
- Delete those commits with
d. - Hit down or up - and see it still selects more commits.
Expected behavior
After deletion, selection mode should be disabled again. That's because if you intended to select more than the commits you already deleted, you would have just kept selecting. So the only sensible thing to do after a deletion is to... go somewhere else, not keep selecting.
Version info:
commit=, build date=, build source=nix, version=0.51.1, os=linux, arch=amd64, git version=2.49.0
Automatically exit selection mode after a bulk operation (like d for delete). Optionally: Introduce a config option to retain selection mode post-action, defaulting to false.
@wolfgangwalther I can't reproduce this. If I select multiple commits using a sticky (v) range and delete them, the selection is collapsed down to a single item, and range selection is cancelled. The same happens when you squash or fixup a range of commit using s or f. This also matches what I see in the code: the "drop" handler calls interactiveRebase, which calls SetSelection, which calls CancelRangeSelect.
The situation is different when you are in an interactive rebase. In that case, commits are not deleted, but their status is only set to "drop". This doesn't change the selection, and I'd say it's reasonable to keep the range selection in this case.
We had a bit of a discussion about this in #3196; originally the proposal was for any command to clear the range selection (except for moving commits up/down, obviously). We then decided to change this to only those commands that remove items from a list, and keep the range for all others. We can of course question this again, but I find this to be a reasonable rule in general.
I can't reproduce this. If I select multiple commits using a sticky (
v) range and delete them, the selection is collapsed down to a single item, and range selection is cancelled.
Hmm, odd. I can't reproduce it right now either. But it didn't happen only once, it happened repeatedly for multiple weeks, before I finally got annoyed enough to report it. And it did happen for sure when I was reporting it, too.
The situation is different when you are in an interactive rebase. In that case, commits are not deleted, but their status is only set to "drop". This doesn't change the selection, and I'd say it's reasonable to keep the range selection in this case.
Absolutely, yes.
We then decided to change this to only those commands that remove items from a list, and keep the range for all others. We can of course question this again, but I find this to be a reasonable rule in general.
That's exactly what I would expect, too - only it didn't happen for me.
In case it happens again, I will re-open.
It now happened again for me, this time in the stash list. Removing multiple stashes keeps the selection mode enabled. Reproduces after a restart, too.
Ah yes, I have seen this too with stashes. That's different code; every panel has it's own handler for deleting things.
What it takes here is an audit of all handlers that handle the delete key and check if they do the right thing. So far we know that the Commits panel does, and the Stashes panel does not.