Skip to content

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

Description

@mc-butler

Important

This issue was migrated from Trac:

Origin https://midnight-commander.org/ticket/3551
Reporter rulatir (rulatir@….pl)
Mentions egmont (@egmontkob)

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.

Activity

  1. mc-butler commented on Nov 12, 2015

    @mc-butler
    Author

    Changed by andrew_b (@aborodin) on Nov 12, 2015 at 6:17 UTC (comment 1)

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

    Apparently wontfix.

  2. mc-butler commented on Nov 12, 2015

    @mc-butler
    Author

    Changed by rulatir (rulatir@….pl) on Nov 12, 2015 at 8:25 UTC (comment 2)

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

  3. mc-butler commented on Nov 12, 2015

    @mc-butler
    Author

    Changed by mooffie (@mooffie) on Nov 12, 2015 at 14:34 UTC (comment 3)

    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 mc2 to address this.)

  4. mc-butler commented on Nov 12, 2015

    @mc-butler
    Author

    Changed by egmont (@egmontkob) on Nov 12, 2015 at 21:54 UTC (comment 4)

    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?

  5. mc-butler commented on Nov 12, 2015

    @mc-butler
    Author

    Changed by rulatir (rulatir@….pl) on Nov 12, 2015 at 22:43 UTC (comment 5)

    @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.

  6. mc-butler commented on Nov 13, 2015

    @mc-butler
    Author

    Changed by andrew_b (@aborodin) on Nov 13, 2015 at 5:28 UTC (comment 4.6)

    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.

  7. mc-butler commented on Nov 13, 2015

    @mc-butler
    Author

    Changed by egmont (@egmontkob) on Nov 13, 2015 at 7:33 UTC (comment 6.7)

    Try Shift-F8.

    I know I know!

  8. mc-butler commented on Nov 13, 2015

    @mc-butler
    Author

    Changed by egmont (@egmontkob) on Nov 13, 2015 at 7:35 UTC (comment 5.8)

    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.

  9. mc-butler commented on Nov 13, 2015

    @mc-butler
    Author

    Changed by egmont (@egmontkob) on Nov 13, 2015 at 7:39 UTC (comment 9)

    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.

  10. mc-butler commented on Nov 13, 2015

    @mc-butler
    Author

    Changed by ossi (@ossilator) on Nov 13, 2015 at 8:34 UTC (comment 9.10)

    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 ('+').

  11. mc-butler commented on Nov 13, 2015

    @mc-butler
    Author

    Changed by rulatir (rulatir@….pl) on Nov 13, 2015 at 11:43 UTC (comment 10.11)

    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.

  12. mc-butler commented on Nov 13, 2015

    @mc-butler
    Author

    Changed by mooffie (@mooffie) on Nov 13, 2015 at 12:08 UTC (comment 10.12)

    Replying to ossi:

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


    Related tickets:

  13. mc-butler commented on Nov 13, 2015

    @mc-butler
    Author

    Changed by ossi (@ossilator) on Nov 13, 2015 at 12:11 UTC (comment 13)

    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.

  14. mc-butler commented on Nov 13, 2015

    @mc-butler
    Author

    Changed by mooffie (@mooffie) on Nov 13, 2015 at 12:38 UTC (comment 13.14)

    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" (#1879) a while ago (I wanted to implement it in mc2) but I couldn't quite figure out how it worked (their manual didn't explain). I added a comment at #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".)

  15. mc-butler commented on Nov 14, 2015

    @mc-butler
    Author

    Changed by egmont (@egmontkob) on Nov 14, 2015 at 16:28 UTC (comment 13.15)

    • Cc set to 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.

  16. mc-butler commented on Nov 14, 2015

    @mc-butler
    Author

    Changed by egmont (@egmontkob) on Nov 14, 2015 at 16:38 UTC (comment 10.16)

    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.

  17. added theissue type on Feb 28, 2025
  18. tuffnatty commented on Sep 28, 2026

    @tuffnatty
    Contributor

    Changed by egmont (@egmontkob) on Nov 14, 2015 at 16:38 UTC (comment 10.16)
    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.

    This particular obstacle can be resolved with #5165.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: coreIssues not related to a specific subsystemprio: mediumHas the potential to affect progress

    Type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions