savannah: escape key timeout stuff

[slavazanko]

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

Discussion:

Wed 20 Sep 2006 03:41:52 PM UTC, comment #8:

I'd like to be able to set it to 0 ms, i.e. Escape behaving as 
Escape and nothing else.
	Miguel Pérez <wiseman1024>
Sat 12 Aug 2006 07:22:02 AM UTC, comment #7:

Denis Vlasenko's patch has been commited.
	Pavel Tsekov <ptsekov>
Project AdministratorIn charge of this item.
Wed 01 Mar 2006 08:09:41 PM UTC, comment #6:

> [...] 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.
	Oswald Buddenhagen <ossi>
Wed 01 Mar 2006 07:47:46 PM UTC, comment #5:

> > 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.
	Pavel Tsekov <ptsekov>
Project AdministratorIn charge of this item.
Wed 01 Mar 2006 07:25:41 PM UTC, comment #4:

> 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.
	Oswald Buddenhagen <ossi>
Wed 01 Mar 2006 07:17:35 PM UTC, comment #3:

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 ?
	Pavel Tsekov <ptsekov>
Project AdministratorIn charge of this item.
Wed 01 Mar 2006 06:59:42 PM UTC, comment #2:

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 ;).
	Oswald Buddenhagen <ossi>
Wed 01 Mar 2006 05:11:49 PM UTC, comment #1:

Please, test the attached patch. Comment, flames, etc will be much 
appreciated.
	Pavel Tsekov <ptsekov>
Project AdministratorIn charge of this item.
Mon 11 Jul 2005 05:27:22 PM UTC, 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. 

[slavazanko]

added by ptsekov