mroussel@alchemy.chem.utoronto.ca (Marc Roussel) (10/03/90)
It often happens when using vi that the arrow keys get misinterpreted
somehow. Lines are then inserted with capital letters on them and one
is left in edit mode. This seems to happen a lot when working over slow
lines. Now I seem to remember hearing once that :set notimeout will fix
this. Is this true? What does (no)timeout control exactly? None of
our local documentation, books or man pages seem to document this
option.
Marc R. Roussel
mroussel@alchemy.chem.utoronto.caterry@uts.amdahl.com (Lewis T. Flynn) (10/04/90)
In article <1990Oct2.211454.1195@alchemy.chem.utoronto.ca> mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes: >It often happens when using vi that the arrow keys get misinterpreted >somehow. Lines are then inserted with capital letters on them and one >is left in edit mode. This seems to happen a lot when working over slow >lines. Now I seem to remember hearing once that :set notimeout will fix >this. Is this true? What does (no)timeout control exactly? None of >our local documentation, books or man pages seem to document this >option. The System V version of vi doesn't use curses/terminfo for cursor movement. It, instead, does cursor handling itself (it probably has to given its interface). When the cursor sequence is <esc>-something (like on a vt100), it uses an alarm to decide when it's a cursor sequence and when it's only an <esc> followed by some unconnected data. If the alarm signal is received before it decides it has a cursor motion sequence, then it must be a standalone <esc>. The catch here is that, in at least some System V implementations, alarms are signaled on 1 second boundaries and if you say alarm(1), you don't get the signal in 1 second, you get it between 0 and 1 seconds, i.e. when the next second boundary comes along. This means that the alarm may come along only milliseconds after it was issued. Thus, what you see is vi getting the <esc>, doing whatever is appropriate with the escape, and then obeying the remainder of the cursor escape sequence as if you had typed it. BSD systems don't have this problem because, I think, setitimer() has different and better semantics (I'm making an assumption that setitimer() is what is used and another one in assuming that BSD vi works the same way). :set notimeout disables the alarm so that the escape sequences are interpreted correctly. It does seem to be slower, however. I would complain to your vendor (this is a bug in my opinion), and in the mean time, get used to using "hjkl" as cursor keys. I would recommend using control keys, but only ^N, ^P, and ^H seem to be defined. If it's possible to map cursor motion, I'd like to learn how. Terry disclaimer: Amdahl's position on this is whatever the support group says when you call them and ask them about it.
guy@auspex.auspex.com (Guy Harris) (10/09/90)
>BSD systems don't have this problem because, I think, setitimer() has >different and better semantics (I'm making an assumption that setitimer() >is what is used bootme% pwd /disks/alpha1/5c/unix_src/bsd4.3-tahoe/usr/src/ucb/ex bootme% egrep setitimer *.[ch] "I see no setitimer here". BSD's "vi" uses "alarm()". Dunno what else is different; if you have both flavors of source handy, you can find out yourself....