Ticket #3957 (closed enhancement: wontfix)

Opened 11 months ago

Last modified 5 months ago

Confirm before opening file

Reported by: Aenfa Owned by:
Priority: major Milestone:
Component: mc-core Version: master
Keywords: Cc: egmont
Blocked By: Blocking:
Branch state: no branch Votes for changeset:

Description

I would really like an option to confirm before opening a file. Countless times I have accidentally opened a file when I was meant to open a directory. The big problem is when it's a large file that MC displays all on the terminal. This completely floods my terminal and can even cause it to completely freeze up.

Change History

comment:1 in reply to: ↑ description ; follow-up: ↓ 2 Changed 11 months ago by andrew_b

Replying to Aenfa:

I would really like an option to confirm before opening a file.

Opening file where?

comment:2 in reply to: ↑ 1 ; follow-up: ↓ 3 Changed 11 months ago by Aenfa

Replying to andrew_b:

Replying to Aenfa:

I would really like an option to confirm before opening a file.

Opening file where?

Any file when pressing enter or double clicking. E.g. I have an initrd.img file directly below the /var directory and I sometimes scroll down one too far and accidentally open the initrd.img file when pressing enter. This floods my terminal with gibberish and often causes it to completely freeze up if it can't take it. It's very frustrating when this happens.

comment:3 in reply to: ↑ 2 Changed 11 months ago by andrew_b

Replying to Aenfa:

Replying to andrew_b:

Replying to Aenfa:

I would really like an option to confirm before opening a file.

Opening file where?

Any file when pressing enter or double clicking.

It depends.

Menu->Options->Confirmation->Execute for executable files.
Editor has the progress window when file is opened.
Viewer opens file very fast since it reads file by portions. If file is large the opening requires some time, it's obviously.
Archives also require some time to open, it's obviously too. See #2011.

comment:4 follow-up: ↓ 5 Changed 11 months ago by egmont

  • Cc egmont added

This completely floods my terminal

IMO this should be fixed, then. What are those messages?

and can even cause it to completely freeze up

Does it literally "completely freeze up"? If so then this is yet another issue to fix. Or does it just take a long time to complete? This could be improved too, e.g. by allowing to abort in-progress archive extraction and such.

Adding a confirmation before opening ("opening" meaning exactly what? F3 (internal or external viewer)? F4 (internal or external editor) ? entering an archive? ...) sounds like a really bad direction to me. It would be a terribly annoying user experience that probably hardly any user would wish to have.

Plus, if we ask frequently for confirmation on non-destructive operations, probably it becomes a routine to accept them and it becomes more risky that a really important confirmation dialog for a destructive operation is automatically accepted by the user, using finger muscle memory rather than paying close attention. (On a side note, see also #3132.)

comment:5 in reply to: ↑ 4 ; follow-up: ↓ 6 Changed 11 months ago by Aenfa

Replying to egmont:

This completely floods my terminal

IMO this should be fixed, then. What are those messages?

and can even cause it to completely freeze up

Does it literally "completely freeze up"? If so then this is yet another issue to fix. Or does it just take a long time to complete? This could be improved too, e.g. by allowing to abort in-progress archive extraction and such.

It's the terminal that freezes not MC. There's no messages as such. It's just the whole contents of the file being displayed just like as though I have typed cat <file>
.

Adding a confirmation before opening ("opening" meaning exactly what? F3 (internal or external viewer)? F4 (internal or external editor) ? entering an archive? ...) sounds like a really bad direction to me. It would be a terribly annoying user experience that probably hardly any user would wish to have.

Opening by pressing ENTER as I clearly stated in my comment above.
.

Plus, if we ask frequently for confirmation on non-destructive operations, probably it becomes a routine to accept them and it becomes more risky that a really important confirmation dialog for a destructive operation is automatically accepted by the user, using finger muscle memory rather than paying close attention. (On a side note, see also #3132.)

The confirmation is only necessary if it's about to show the whole contents of a large file on the terminal at once. I think it's a setting somewhere that I have missed. I think I just need to set it so it doesn't default to cat to those files.

Last edited 11 months ago by Aenfa (previous) (diff)

comment:6 in reply to: ↑ 5 Changed 11 months ago by egmont

Replying to Aenfa:

It's the terminal that freezes not MC.

Could you please elaborate on this?

It's just the whole contents of the file being displayed just like as though I have typed cat <file>

This seems to contradict your previous statement. Or does even a cat <file> cause a freeze for you?

So, what happens exactly? It starts to behave exactly as if you've typed cat file. mc's blue panels disappear, your terminal's default (probably black or white) background is visible, the file's contents start printing and scrolling quickly. Does it go all the way through, to the end of the file, or does it stall at some earlier phase? Do mc's panels come back afterwards, and if so, do they work properly? In what state does it exactly freeze?

The confirmation is only necessary if it's about to show the whole contents of a large file on the terminal at once.

I think you have really weird defaults configured, I'm wondering if they are mc's defaults acting so strange on your system, to cat a non-executable file when you press Enter on it. Your settings should be double checked.

If it's indeed mc executing an external command due to its configuration, then there's no way mc could know in advance what that external command is going to do, e.g. whether it will cat a large file or not.

At this point first we'd need a much better understanding of what exactly happens, and second we'd need to investigate why that happens. It's way too early to ponder about workaround confirmation dialogs or such.

comment:7 Changed 10 months ago by andrew_b

  • Status changed from new to closed
  • Resolution set to wontfix

No reply about a month.
Closed.

comment:8 Changed 5 months ago by zaytsev

  • Milestone Future Releases deleted
Note: See TracTickets for help on using tickets.