Re: esc key

where 0 means "stick forever", 1 means "stick for some time" (controlled
by esc_delay) and 2 means "do not stick".

I have no idea what it means.  We had a problem with mc+xterm+ncurses
recently when escape would not be recognized by ncurses under heavy load
(i.e. you are entering a tar.bz2 archive).  The fix was to set ncurses'
internal delay to a reasonable non-zero value.  I believe that we would
have a lot of weird problems if the escape delay was exactly 0.

Of course to implement "do not stick", we don't need exactly 0. A few ms would be fine.

I think we can live with one variable esc_delay, and 0 (or maybe -1) would
mean "wait for the next escape forever".

This is possible too, but my proposal has the advantage of maintaining backward compatibility: we can alias 
"old_esc_mode" to be the same as the "esc_mode" and then the old ini files with either old_esc_mode=1 or 
old_esc_mode=0 would continue to work as before. Only if you use the new extended value of 2 you'll get a new 
behavior. Do you think that makes sense?

I don't think so.  It's not uncommon for people to use different terminals
with different speed.  I'm not saying that we necessarily need a GUI.
Maybe we should finally implement terminal-specific settings?

Perhaps, although I personally do not use different terminals so I don't feel this as a priority. IMHO 
implementing an external keymap configuration is more important at this point.

I think it's a huge annoyance when the command line is erased
unexpectedly.  I'm used to running "Find File" by pressing Escape-?, so
I'm losing the command line every time I attempt to do it in Far.

This is why I proposed to enable this binding _only_ for esc_mode=2, i.e. for those who want no delay 
whatsoever and never use esc as a prefix key. 

Sign-up for your own FREE Personalized E-mail at

Meet Singles

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]