Ctrl+Space does not unselect directories it processed, and there's a workflow where this is DANGEROUS

[rulatir]

Consider a workflow the purpose of which is to identify and delete some temporary directories (logs, caches, captured test data) that take lots of disk space.

You enter a directory.

You select all subdirectories.

You press Ctrl+Space to compute their disk space usage.

You identify a disk-hogging dir.

You select it with arrow keys.

You press F8 and OK.

DISASTER!!!!!!!!! because all other subdirectories were still "yellow". The Ctrl+Space command did NOT unselect them after it was done with them!

Please fix this.

[andrew_b]

If you want calculate all subdirectories, there is no need to select anything. Just stay at ".." and press ctrl-space.

Apparently wontfix.

[rulatir]

This trick is not discoverable, and for someone who doesn't know about it the described workflow is still dangerous.

[mooffie]

For the record: FAR and Dos Navigator too don't unmark the files (upon pressing F3).

(But I do think there's a certain usability problem here. I've just added ​a snippet to mc² to address this.)

[egmont]

I've been bitten by similar issue a few times. It happened to me that I selected a couple of files (for whatever reason) and then I thought F8 would delete the one under the cursor.

On one hand, I'm inclined to say it's a user error, i.e. the step "You press F8 and OK" should be changed to "You press F8, get a popup dialog, read and understand what's written there and answer that question".

On the other hand, sure, it would be good to have a protection against it. But what should that be???

Using libtrash or any other similar mechanism so that files are recoverable?

Requiring to press Enter twice in such a circumstance?

Or what else???

I really don't have a clear idea.

@rulatir (the reporter guy): Do you have any idea how to fix this?

[rulatir]

@egmont: As I said in the original submission, the idea is that mc should unmark the directories after executing a command on them.

Multiple selection should be considered a potentially dangerous state, particularly if the selection has already been used as an argument to a non-destructive operation, since this inductively supports the hypothesis that the user does not want to perform destructive operations on that selection.

[andrew_b]

Replying to egmont:

I've been bitten by similar issue a few times. It happened to me that I selected a couple of files (for whatever reason) and then I thought F8 would delete the one under the cursor.

Try Shift-F8.

[egmont]

Try Shift-F8.

I know I know!

[egmont]

Replying to rulatir:

@egmont: As I said in the original submission, the idea is that mc should unmark the directories after executing a command on them.

This would heavily set back on your producvitity and cause frustration if you actually wanted to perform multiple operations on the given set of files.

[egmont]

Another idea: If there's no selected file, F8 would open with "Yes" as the default. If there are some selected files, F8 would open with "No" as the default.

[ossi]

Replying to egmont:
that would be terrible usability.

the argument for unselecting is that the "most basic" file operations (copy, move, etc.) unselect as well. in particular, copy is a read-only operation on the source file, so keeping the selection would be possible. yet it isn't done.

i'll argue that performing multiple operations on the same selection is a corner case, so the interface should not be optimized for it. however, i'll buy that it is quite annoying to not have the option when you actually need it. so i'd suggest an explicit action "repeat previous selection", possibly directly accessible via the '&' char (it's right next to '*' on the us layout, and it's another char that doesn't usefully appear at the start of a command), or at least as the first/default item in the dropdown in the selection dialog ('+').

[rulatir]

Replying to ossi:

the argument for unselecting is that the "most basic" file operations (copy, move, etc.) unselect as well.

This!

i'll argue that performing multiple operations on the same selection is a corner case, so the interface should not be optimized for it. however, i'll buy that it is quite annoying to not have the option when you actually need it. so i'd suggest an explicit action "repeat previous selection",

Some nice ideas here. I have another: prevent destructive actions from reusing a selection that was already used for some action. If this is attempted, then the multiple selection is unselected before performing the destructive action, and said action is instead performed on the currently highlighted item only. This would require a flag in the panel state and some logic to set/clear it at appropriate times, but the benefit is that the user will be able to chain non-destructive actions on the same selection.

[mooffie]

Replying to ossi:

i'd suggest an explicit action "repeat previous selection"

Related tickets:

• ticket:1879 "Have 'restore previous selection' as in FAR"
• ticket:2387 "Persistent file mark"

[ossi]

Replying to rulatir:

prevent destructive actions from reusing a selection that was already used for some action.

the definition of "destructive" is somewhat debatable, and latest when you have user-defined actions, things go entirely out of control. also, it's not a good idea to have semantics which aren't visible in the user interface.

i'd really stick with the single rule: always deselect. the tricky part is then what is stored as the "previous selection" (think about it: copying can be interrupted, the selection amended, copying resumed), but the effect of it is at least immediately visible.

[mooffie]

Replying to ossi:

i'd really stick with the single rule: always deselect.
the tricky part is then what is stored as the "previous selection"

I had a look at FAR's "Restore selection" (ticket:1879) a while ago (I wanted to implement it in mc²) but I couldn't quite figure out how it worked (their manual didn't explain). I added a comment at ticket:1879 asking for details.

(think about it: copying can be interrupted, the selection amended, copying resumed),

(This part is actually easy to solve: by having a stack of "previous selections".)

[egmont]

Replying to ossi:

i'd really stick with the single rule: always deselect.

What does that "always" mean exactly? Probably you wouldn't want to deselect when changing to the other panel with Tab, or opening and closing the F9 menu, or disabling the panel for a short while by pressing Ctrl-O twice in a row, correct?

So I guess it's rather something along the lines of "always deselect after performing an operation that had something to do with the selected files", am I on the right track? But then executing "ls" wouldn't deselect, while executing "ls %t" would? Sounds weird...

It's not that I don't like the approach, it's just that it's not trivial where to draw the line.

When I got hit by this issue a few times, my use case was slightly different. I didn't press Ctrl-Space since I hardly ever use that feature, and never for multiple files. I just selected a couple of files, and than a bit later I forgot that I had done so, I might even have scrolled to a different part of the file listing so that they weren't visible any more, and I just wanted to delete/move that single file under the cursor. Always deselecting wouldn't protect against this.

[egmont]

Replying to ossi:

so i'd suggest an explicit action "repeat previous selection", possibly directly accessible via the '&' char

If we choose this approach, there's a UI issue to address. The feature needs to be discoverable on the UI (not just hidden somewhere deep inside the manpage), and its logical place is next to the select/unselect/invert options in F9 -> File. However, that menu is already as tall as it can be on the default 80x24 terminal size. So we'd need to rearrange the menu items somehow, or perhaps drop Exit from there.