11 | | Wed 20 Sep 2006 03:41:52 PM UTC, comment #8: |
| 11 | so there is this old_esc_mode option ... |
| 12 | it really needs some more exposure. in fact, it should be enabled |
| 13 | by default, and the timeout should be lowered from one second to at |
| 14 | most 100 ms (that is, virtually instantaneous). |
| 15 | high-latency network links should not cause problems, as the chars |
| 16 | of one keypress should still be in one packet, keeping the sequence |
| 17 | intact. if there really is some problem with this, the patch posted |
| 18 | by denis vlasenko on 2004-10-25 to make the timeout configurable |
| 19 | via an environment variable can be used. |
| 20 | }}} |
18 | | Denis Vlasenko's patch has been commited. |
19 | | Pavel Tsekov <ptsekov> |
20 | | Project AdministratorIn charge of this item. |
21 | | Wed 01 Mar 2006 08:09:41 PM UTC, comment #6: |
| 28 | Comment 2 by Oswald Buddenhagen <ossi> at Wed 01 Mar 2006 06:59:42 PM UTC: |
| 29 | {{{ |
| 30 | first a correction on my side: meanwhile i did actually experience |
| 31 | a sequence being torn apart, so the "one packet" theory simply does |
| 32 | not hold. :( |
| 33 | going slightly overboard, one could apply some heuristics to |
| 34 | determine the worst-case line latency automatically. |
23 | | > [...] I cannot imagine why one would need to adjust it more than |
24 | | once. |
| 36 | i'm not sure it is a good idea to make the timeout a proper option |
| 37 | only. it makes sense to have the setting depend on the location, or |
| 38 | rather on the route to the location. an env variable seems to be |
| 39 | the by far the most appropriate means of achieving this. having |
| 40 | separate settings for certain $TERM seems interesting as well, as i |
| 41 | might want to extend the timeout for terms where i have to enter |
| 42 | esc sequences manually - but that can be scripted in the startup |
| 43 | script as well. |
| 44 | other than that the patch seems reasonable (i did not test it, but |
| 45 | i don't see any code paths which you could have skipped if you |
| 46 | tested it at all ;). |
| 47 | }}} |
| 48 | |
| 49 | Comment 3 by Pavel Tsekov <ptsekov> at Wed 01 Mar 2006 07:17:35 PM UTC: |
| 50 | {{{ |
| 51 | Well, one could always adjust it as per his immediate requirements. |
| 52 | Have you noticed that I've added a new configuration dialog ? Why |
| 53 | do you think an environment variable is more appropriate ? |
| 54 | }}} |
| 55 | |
| 56 | Comment 4 by Oswald Buddenhagen <ossi> at Wed 01 Mar 2006 07:25:41 PM UTC: |
| 57 | {{{ |
| 58 | > Well, one could always adjust it as per his immediate requirements. |
44 | | i think the env var should override the setting, but both make |
45 | | sense. ideally, the config dialog would show whether the setting |
46 | | will take effect - to avoid surprises. |
47 | | Oswald Buddenhagen <ossi> |
48 | | Wed 01 Mar 2006 07:47:46 PM UTC, comment #5: |
| 71 | it is scriptable. without sed-ing the config file, that is. |
| 72 | in the scenarios i drafted this option is rather imposed by the |
| 73 | operation environment than by user preference, so it just makes |
| 74 | sense to use something that is naturally part of the environment. |
| 75 | }}} |
98 | | it is scriptable. without sed-ing the config file, that is. |
99 | | in the scenarios i drafted this option is rather imposed by the |
100 | | operation environment than by user preference, so it just makes |
101 | | sense to use something that is naturally part of the environment. |
102 | | Oswald Buddenhagen <ossi> |
103 | | Wed 01 Mar 2006 07:17:35 PM UTC, comment #3: |
| 135 | i think the env var should override the setting, but both make |
| 136 | sense. ideally, the config dialog would show whether the setting |
| 137 | will take effect - to avoid surprises. |
| 138 | }}} |
112 | | first a correction on my side: meanwhile i did actually experience |
113 | | a sequence being torn apart, so the "one packet" theory simply does |
114 | | not hold. :( |
115 | | going slightly overboard, one could apply some heuristics to |
116 | | determine the worst-case line latency automatically. |
117 | | |
118 | | i'm not sure it is a good idea to make the timeout a proper option |
119 | | only. it makes sense to have the setting depend on the location, or |
120 | | rather on the route to the location. an env variable seems to be |
121 | | the by far the most appropriate means of achieving this. having |
122 | | separate settings for certain $TERM seems interesting as well, as i |
123 | | might want to extend the timeout for terms where i have to enter |
124 | | esc sequences manually - but that can be scripted in the startup |
125 | | script as well. |
126 | | other than that the patch seems reasonable (i did not test it, but |
127 | | i don't see any code paths which you could have skipped if you |
128 | | tested it at all ;). |
129 | | Oswald Buddenhagen <ossi> |
130 | | Wed 01 Mar 2006 05:11:49 PM UTC, comment #1: |
131 | | |
132 | | Please, test the attached patch. Comment, flames, etc will be much |
133 | | appreciated. |
134 | | Pavel Tsekov <ptsekov> |
135 | | Project AdministratorIn charge of this item. |
136 | | Mon 11 Jul 2005 05:27:22 PM UTC, original submission: |
137 | | |
138 | | so there is this old_esc_mode option ... |
139 | | it really needs some more exposure. in fact, it should be enabled |
140 | | by default, and the timeout should be lowered from one second to at |
141 | | most 100 ms (that is, virtually instantaneous). |
142 | | high-latency network links should not cause problems, as the chars |
143 | | of one keypress should still be in one packet, keeping the sequence |
144 | | intact. if there really is some problem with this, the patch posted |
145 | | by denis vlasenko on 2004-10-25 to make the timeout configurable |
146 | | via an environment variable can be used. |
| 145 | Comment 8 by Miguel Pérez <wiseman1024> at Wed 20 Sep 2006 03:41:52 PM UTC: |
| 146 | {{{ |
| 147 | I'd like to be able to set it to 0 ms, i.e. Escape behaving as |
| 148 | Escape and nothing else. |