Ticket #23 (closed enhancement: wontfix)
savannah: escape key timeout stuff
Reported by: | ossi | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | 4.7 |
Component: | mc-core | Version: | |
Keywords: | Cc: | zaytsev | |
Blocked By: | Blocking: | ||
Branch state: | no branch | Votes for changeset: |
Description (last modified by ossi) (diff)
Original: http://savannah.gnu.org/bugs/?13733
Submitted by: | Oswald Buddenhagen <ossi> | Submitted on: | Mon 11 Jul 2005 05:27:22 PM UTC |
Category: | Keyboard input | Severity: | 3 - Normal |
Status: | Ready For Test | Privacy: | Public |
Assigned to: | Pavel Tsekov <ptsekov> | Open/Closed: | Open |
Release: | current (CVS or snapshot) | Operating System: | All |
Original submission:
so there is this old_esc_mode option ... it really needs some more exposure. in fact, it should be enabled by default, and the timeout should be lowered from one second to at most 100 ms (that is, virtually instantaneous). high-latency network links should not cause problems, as the chars of one keypress should still be in one packet, keeping the sequence intact. if there really is some problem with this, the patch posted by denis vlasenko on 2004-10-25 to make the timeout configurable via an environment variable can be used.
Comment 1 by Pavel Tsekov <ptsekov> at Wed 01 Mar 2006 05:11:49 PM UTC:
Please, test the attached patch. Comment, flames, etc will be much appreciated.
Comment 2 by Oswald Buddenhagen <ossi> at Wed 01 Mar 2006 06:59:42 PM UTC:
first a correction on my side: meanwhile i did actually experience a sequence being torn apart, so the "one packet" theory simply does not hold. :( going slightly overboard, one could apply some heuristics to determine the worst-case line latency automatically. i'm not sure it is a good idea to make the timeout a proper option only. it makes sense to have the setting depend on the location, or rather on the route to the location. an env variable seems to be the by far the most appropriate means of achieving this. having separate settings for certain $TERM seems interesting as well, as i might want to extend the timeout for terms where i have to enter esc sequences manually - but that can be scripted in the startup script as well. other than that the patch seems reasonable (i did not test it, but i don't see any code paths which you could have skipped if you tested it at all ;).
Comment 3 by Pavel Tsekov <ptsekov> at Wed 01 Mar 2006 07:17:35 PM UTC:
Well, one could always adjust it as per his immediate requirements. Have you noticed that I've added a new configuration dialog ? Why do you think an environment variable is more appropriate ?
Comment 4 by Oswald Buddenhagen <ossi> at Wed 01 Mar 2006 07:25:41 PM UTC:
> Well, one could always adjust it as per his immediate requirements. > this is slow. and extremely annoying if done several times a day. > Have you noticed that I've added a new configuration dialog ? > no, i did not read your patch. ;-) > Why do you think an environment variable is more appropriate ? > it is scriptable. without sed-ing the config file, that is. in the scenarios i drafted this option is rather imposed by the operation environment than by user preference, so it just makes sense to use something that is naturally part of the environment.
Comment 5 by Pavel Tsekov <ptsekov> at Wed 01 Mar 2006 07:47:46 PM UTC:
> > Well, one could always adjust it as per his immediate requirements. > > > this is slow. and extremely annoying if done several times a day. Maybe I am missing the point but I cannot imagine why one would need to adjust it more than once. Maybe if one logs into a single network host from multiple sources... But still this option makes sense mostly when used on a local machine. I think that beyond certain values enabling this option is not usefull at all. > > Have you noticed that I've added a new configuration dialog ? > > > no, i did not read your patch. ;-) You could try it at least :) It doesn't change the default behaviour it just adds the ability to configure old_esc_mode and the related timeout (I should have mentioned that earlier). > > Why do you think an environment variable is more appropriate ? > > > it is scriptable. without sed-ing the config file, that is. > in the scenarios i drafted this option is rather imposed by the operation > environment than by user preference, so it just makes sense to use something > that is naturally part of the environment. In this case Denis Vlasenko's patch should suffice.
Comment 6 by Oswald Buddenhagen <ossi> at Wed 01 Mar 2006 08:09:41 PM UTC:
> [...] I cannot imagine why one would need to adjust it more than once. > you can log into the same machine from different sources - locally, through serial line, through networks with different latencies. and also you can share the same config among several machines if you have a networked home. both cases are not exactly exceptional in heterogenous environments like unis or even when simply ssh-ing into your box at home. > > no, i did not read your patch. ;-) > > You could try it at least :) [...] > oil your irony detector, dude. ;) > In this case Denis Vlasenko's patch should suffice. > i think the env var should override the setting, but both make sense. ideally, the config dialog would show whether the setting will take effect - to avoid surprises.
Comment 7 by Pavel Tsekov <ptsekov> at Sat 12 Aug 2006 07:22:02 AM UTC:
Denis Vlasenko's patch has been commited.
Comment 8 by Miguel Pérez <wiseman1024> at Wed 20 Sep 2006 03:41:52 PM UTC:
I'd like to be able to set it to 0 ms, i.e. Escape behaving as Escape and nothing else.
Attachments
Change History
Changed 16 years ago by slavazanko
- Attachment mc-old_esc_mode.patch added
comment:3 Changed 15 years ago by angel_il
- Type changed from defect to enhancement
- severity set to no branch
- Milestone changed from Future Releases to 4.7
comment:4 Changed 14 years ago by ossi
- Cc ossi@… added
given that vda's patch was committed and serves the purpose well, i'd just close this ticket.
comment:5 Changed 14 years ago by ossi
no, wait, the default timeout should be reduced. i'm running with 50ms (instead of 1s). that should be ok for most cases.
comment:6 Changed 14 years ago by andrew_b
If you can't use alt as meta, you need use esc as meta. Short timeout doesn't allow you use esc as meta. 1s is enough time to press next key.
comment:7 Changed 14 years ago by ossi
that's besides the point. we are talking about the default. the default should not be optimized towards a few setups with broken/stone-aged terminals, but towards the majority.
comment:8 Changed 14 years ago by andrew_b
Yes, we are talking about the default. Current default is optimum for those people who need to use esc as meta not in terminal but in X Window.
Example: the alt-shift shortcut is used in X to change the keyboard language layout (en/ru, en/de, en/...). Can you use the alt-shift-/ shortcut to find files if MC is runing in termina emulator? If no, you need use esc shift-/ key combination. If timeout is short, you cannot time to press shift-/ after pressing esc.
comment:9 follow-up: ↓ 15 Changed 14 years ago by ossi
if you have an x11 layout switcher which reacts to alt-shift even if some other key was pressed additionally, then you should a) kill the guy who made it and b) get yourself a sane switcher.
there really is no reason to break the experience of everyone else for the sake of a few people who use broken (or badly configured) software.
comment:10 Changed 14 years ago by zaytsev
- Cc zaytsev added
Aha, we change the default and the shit hits the fan again. Both vda's patch and a config dialog setting are there now, for those who want to change it without any hassle. What's the point?
I agree that this ticket should be closed though.
comment:11 Changed 14 years ago by ossi
so let it hit. no noteworthy detriment will come out of it.
the point is optimizing the out-of-the-box experience. delivering stuff that just works (for the vast majority). user friendliness, you know.
fwiw, afaict, the config dialog is not in, and imo it's good that way.
comment:12 Changed 14 years ago by zaytsev
It is in on 4.7.3-23-gc9d0301, f9 -> o -> c -> i.
User-friendliness is a relative notion. I am one of those, who often use esc as meta (and most of those, dealing with Cyrillic are for various reasons), so this change will de-optimize out-of-the-box experience for me.
Whom do I care most about...? :)
comment:13 Changed 14 years ago by ossi
oh, there it is hidden. :)
it has no indicator that the env variable will override it, right?
i'd argue that as a user of a cyrillic layout you cannot have a good out-of-the-box experience in this regard anyway - no fresh user would know that he can create escape sequences manually. consequently it seems reasonable to optimize the case which has a chance to "just work" at all, and let those who will have to look into the manual anyway change the configuration.
regarding *your* personal experience (and the one of other experienced users): i don't think that changing one option more per new account is a particularly loathsome experience. ;)
comment:14 Changed 14 years ago by zaytsev
I am not sure about the current state of affairs with the regards of the environment variable. If it is the case, this probably has to be documented and actually makes sense.
comment:15 in reply to: ↑ 9 Changed 14 years ago by andrew_b
Replying to ossi:
if you have an x11 layout switcher which reacts to alt-shift even if some other key was pressed additionally, then you should a) kill the guy who made it and b) get yourself a sane switcher.
there really is no reason to break the experience of everyone else for the sake of a few people who use broken (or badly configured) software.
Ok. forget alt-shift. This is lame example. What can you tell about meta-tab? In MC meta-tab is used for autocompletion in editor, command line, some input lines. In X11 the alt-tab is used to switch windows and MC doesn't get this event, of course. Since alt-tab cannot be used for autocompletion, the esc tab is a only way for that. The default 1s timeout allows you to use this feature, 50mc (or even 100ms) doesn't.
comment:16 follow-up: ↓ 17 Changed 14 years ago by ossi
on a modern keyboard you could configure win-tab for window switching.
anyway, this is indeed an issue which annoys the heck out of me. and suggesting to use esc-tab instead is positively not a relevant suggestion. that's why some months ago in a different discussion about shortcuts i suggested using ctrl-space as a general solution for that problem.
so, you still need to come up with a good example. :P
comment:17 in reply to: ↑ 16 ; follow-up: ↓ 18 Changed 14 years ago by andrew_b
Replying to ossi:
on a modern keyboard you could configure win-tab for window switching.
And you could configure MC with the same easiness. Where is the logic? :)
comment:18 in reply to: ↑ 17 Changed 14 years ago by ossi
Replying to andrew_b:
And you could configure MC with the same easiness. Where is the logic? :)
a) applications are less likely to use the win(-dows (management)) key, so this creates potentially more compatibility in general
b) the so-called "legacy" window managers don't grab alt-tab, just like the linux console doesn't. so it's more in line with unix traditions to have that combo free for applications - otherwise mc wouldn't have used it in the first place
c) there is no word about excluding other approaches in it at all
and d) i still prefer changing the default mapping to ctrl-space, which is a common completion shortcut in IDEs and is not expected to cause other conflicts (except possibly in mc itself)
comment:19 Changed 14 years ago by andrew_b
- Status changed from new to closed
- Resolution set to wontfix
So...
Esc key mode (single or double press) is available via configuration dialog. Default mode is double press. Timeout for single press can be set when the single press mode is activated.
comment:20 Changed 11 years ago by ossi
- Cc ossi@… removed
- Description modified (diff)
- Branch state set to no branch
- Reporter changed from slavazanko to ossi
added by ptsekov