Single ESC in place of double

[sergey-feo]

(Sorry for my bad English)

Why user should press ESC twice to exit from dialogs? Why not once?

It can be because of historic reasins or it can be for Emacs-like keybindings. But now is year 2009 and de-facto standart is single-pressed ESC. What do you think about change ESC behaviour to single-pressed? If double ESC is really needed for some users then some options can be added for enabling old behaviour.

[angel_il]

set variable KEYBOARD_KEY_TIMEOUT_US
in your profile

export KEYBOARD_KEY_TIMEOUT_US=1000

set old_esc_mode
in ~/.mc/ini

old_esc_mode=1

have nice a day

[sergey-feo]

Great, thanks! :-)

1. Why this option disabled by default?
2. What the secret string KEYBOARD_KEY_TIMEOUT_US=1000 is mean?
3. This option must present in configuration dialog. I think that many users that want single ESC do not know about it existence.

[angel_il]

3. This option must present in configuration dialog. I think that many users that want single ESC do not know about it existence.

"many user" can read the 'man'.

KEYBOARD_KEY_TIMEOUT_US=1000 is mean

1000 = 1ms

please read
​http://mail.gnome.org/archives/mc-devel/2006-July/msg00084.html

[angel_il]

old_esc_mode

By default the Midnight Commander treats the ESC key as a key prefix
(old_esc_mode=0). If this option is set (old_esc_mode=1), the ESC key
will act as a prefix key for one second, and if no extra keys have
arrived, then the ESC key is interpreted as a cancel key (ESC ESC).

[sergey-feo]

Thank you for detailed answer!

But the question 1 is without answer still. I will take some audacity and write example that can show absurdity of default double ESC.

Please imagine that you buy new DVD recorder.
Once you want to record some TV program. You press rec button - record begins.
Then you press stop button - record does not stop. You press pause button. DVD recorder shows garbage "[18~" on the screen. With quick experiment you learn that you must press stop twice to stop the record. Many users of this strange recorder want single-stop but use double-stop.
And many users can read the service manual. This manual describes what jumpers should be set on recorder printed circuit board to enable single-stop feature.

Unashamed but IMHO reasonable criticism :-)

[andrew_b]

In UNIX world, ESC is not a command itself. It's a command prefix. So complete command is "ESC ESC".

[iNode]

Please try to do completion by Alt-Tab (I guess you use any user friendly WM/DM), and you understand why Esc-Tab need. :)

[angel_il]

you can replace Alt-Tab in Option\Learn keys, select [Completion/M-tab] and press new key. I use S-Tab as Completion

[sergey-feo]

Please try to do completion by Alt-Tab (I guess you use any user friendly WM/DM), and you
understand why Esc-Tab need. :)

I use Window Maker and switch windows by Ctrl + ← and Ctrl + →, so I have no problems with Alt+Tab completion :-)
By the way, why only Alt+Tab or Esc+Tab? Why not Alt+~ or Shift+F12 or Menu+] or something else? Keyboard can have many other combinations. angel_il's S+Tab is also exellent variant.

In UNIX world, ESC is not a command itself. It's a command prefix

This is strange tradition. We have many other prefix keys and ESC is very useful by itself.
Let see at the keys names.
Esc is escape. This name does not suppose that Esc is prefix. This key has cancel function by its name.
Alt + key means "alternative key function". Alt is prefix by its name.
Ctrl + key means some control function that sounds like prefixed key. So, ctrl is prefix by its name.
Shift + key means shifted register, upper symbol that printed on the key. Shift is good prefix key by its name.
But Esc is not. Esc is Esc and IMHO should be Esc :-)

[slavazanko]

This is strange tradition.

This normal tradition (if you use really stupid terminals - like Windows HyperTerminal).

Esc is escape.

Try to look to 'Esc' key as action of command. 'Esc'ape what? 'Escape 1' = 'Function 1' (F1), 'Escape 2' equal to 'Function 2' (F2) etc...

But Esc is not. Esc is Esc and IMHO should be Esc :-)

angel_il give to you detailed solution how to handle Esc as 'Escape'. If you want this as default behavior, please touch maintainers of your distro. We just provide some default configuration(worked on many OSes and terminals as possible).

[sergey-feo]

Try to look to 'Esc' key as action of command. 'Esc'ape what? 'Escape 1' = 'Function 1' (F1)

I agree that it can be considered as action of command, in other word as prefix key like Ctrl.

If you want this as default behavior, please touch maintainers of your distro

My distro is Slackware. This distro uses unmodified software. This is why I can talk about software with its authors directly, not throut distributive authors.

OK, let stop this discussion. I understood you position:
double Esc is because Esc used as command prefix. This is good old Unix tradition that make it possible to run mc on many different terminals.

My position is that Esc should has just "cancel" function and this is good old DOS tradition.

mc has this option. It is not and will not default.

[ossi]

this is a purely technical decision. the escape character starts escape sequences, which is how most control keys are delivered to the application (and also how most control codes are delivered to the terminal). the application simply cannot know whether the actual esc key was pressed or the esc is starting an escape sequence. it can guess based on a timeout - see the environment variable - but that's unreliable, as a high-latency remote login can then easily break esc sequences. the best thing you can do really is teaching your terminal to send two escape chars when the escape key is pressed - provided your terminal supports such a feature. in any case a generic solution is out of mc's control.

[sergey-feo]

This is very interesting information.
I try to see keys -> entered symbols correspond in Konsole, Terminal and Roxerm.

Esc key returns Esc (27dec) and F1 returns Esc+O+P. It makes really problematic on noisly lines to determine what was happened: Esc and long pause or begin of F1 and long pause.

I was surprized that this terminal emulators does not make differences between some keys and combinations.
For example, both Esc+q and Alt+q returns Esc+q.
Both Return and Ctrl+J returns 10dec.
I think it is very bad for terminal application like mc.

Learn terminal emulator to give application Esc+Esc (27dec+27dec) when Esc is pressed is good idea. We can treat Esc+Esc as esc-sequence that means Esc key. If esc-sequenses exists then must be a way to determine real single Esc key. Sequence Esc+Esc is good for this.

I see how other terminal applications reacts on Esc+Esc. Esc+Esc is cancel command for Minicom and Links. This applications also treat Esc key+pause as cancel command. Jed does not understand Esc+Esc but understand Esc+pause.

With current keys to symbols mapping traditions in many terminal emulators application can't see difference between Esc key pressing and begin of esc-sequence. This problem can bee partially solved by treating Esc+pause as Esc key pressing. Or this can be fully solved by using Esc+Esc sequence for pressed Esc key in both terminal emulator and application.

I suggest to write something about this 2 methods in mc's hint line (to give to user hint that problem can be solved and where user can read about this).

[vda]

Replying to ossi:

this is a purely technical decision. the escape character starts escape sequences, which is how most control keys are delivered to the application (and also how most control codes are delivered to the terminal). the application simply cannot know whether the actual esc key was pressed or the esc is starting an escape sequence.

Sorry, but you look at the problem from the wrong angle. Yes, ESC key is used as a prefix for control keys, and also it can be generated on its own by pressing ESC key. In hindsight, this is a bad design, and it cannot be changed now for historical reasons.

But why users must suffer as a result? We, IT people (collectively speaking) screwed this whole situation up, not users.

Instead of telling poor victims what are the technical details of this desig disaster they are suffering from, we are better to work to make it stop hurting people.

it can guess based on a timeout - see the environment variable

E-xac-tly! It's not a rocket science!

• but that's unreliable,

Yes, it's a hack. There is no clean solution. The question is, how often this hack fails? From my experience with KEYBOARD_KEY_TIMEOUT_US=25000 setting - it never fails for me.

as a high-latency remote login can then easily break esc sequences.

Did you actually try it?

Network logins send all chars of a key sequence in the same packet 99.99999999% of the time (you need to type like mad to fill internal buffers and make it remotely likely that key sequence will straddle packet - I never succeeded achieving it), so receiving side never sees any delay at all between chars from the same key. So it's reliable in this scenario.

Serial lines insert delays, but with 25 ms delay for "lone ESC" detection on the receiver side you need to use serial line with less than 500 bits per second to risk seeing it. Today's serial lines are *way* faster than that. Hack would work in this scenario too.

Similar code detects key sequences in busybox very reliably.

the best thing you can do really is teaching your terminal to send two escape chars when the escape key is pressed - provided your terminal supports such a feature. in any case a generic solution is out of mc's control.

I propose changing hardcoded 1 second delay for old_esc_mode to 25 or 50 milliseconds instead, and exposing old_esc_mode in configuration dialogs. That's all what needed.

[ossi]

Replying to vda:

Replying to ossi:

as a high-latency remote login can then easily break esc sequences.

Did you actually try it?

yes

Network logins send all chars of a key sequence in the same packet 99.99999999% of the time

i thought that, too. unfortunately, the reality proved different. i don't remember what exact test setup i used back then (several years) - it might be in the ml archive. most likely it was ssh-in-xterm-on-linux into some other system, but that's speculation.

[zaytsev]

Replying to vda:

I propose changing hardcoded 1 second delay for old_esc_mode to 25 or 50 milliseconds instead, and exposing old_esc_mode in configuration dialogs. That's all what needed.

I WANT THIS NOW :))))

[sorin]

Is it ok to have this bug closed as invalid. I am using the latest version and still I am not able to find a configuration which would prevent me from seeing invalid ESC codes after I close a mcedit window.

Use case: you are in editor, press ESC and UP or DOWN keys.

Effect, in most cases you will see an additional OB or OA on the command line.

I tried enabling single ESC mode, with 1000 delay, 100 delay, 1 delay and even 0, still it seems that all of them will eventually get you some garbage form ESCaped stuff. While I do think setting the delay lower does lower the change of getting the garbage it still does not prevent it and if you quit enough, it's quite easy to trigger it.

Do we have any change of developing a real solution for this?

[andrew_b]

See #3136.

[dandv]

It's amazing that after 5 years, the developers still decide to force users into 20-year old UNIX traditions.

Think from the perspective of a new user to MC. Who cares, among regular users (who by now are far more numerous than devs) that the tradition was double-ESC, or that for whatever tech reason, we have to use ESC before commands? That is just pointless now, when all other applications use "normal" key bindings.

Does any other app use ESC-ESC to exit a dialog? No. Because it doesn't make sense.

Please fix this.

[sorin]

I am wondering if there is a proper way to fix this once for all, I've been using it for probably 15 years, and the ESC problem with MC still hit me every day.