Key sequences and timing in vi
Privileged Account
>
>I have defined some vi macros in my shell variable EXINIT. Some of them I
>use to execute certain shell scripts like:
>
>map @s :w
>
>which checks the current file for spelling errors (of course I have used it
>for this article :-)
I think you meant:
map @s :w !spell^M (the ^M is a control-M, of course)
>Sometimes invocation of this macro (by typing @s in edit mode) fails with
>the error: "Nothing in register s"
You could consider putting the string @s in register s. Or, to prevent
looping, the string :w !spell^M. (In this version of vi, putting @s in s
doesn't loop, but you never know what the next release is going to do.)
>It seems to happen when there is too much time between typing the "@" and "s".
>Is this true ?
Yes it is.
> If so: what is the time limit ?
1 second. A bit longer if your system is heavily loaded.
> Is there a bypass for always
>successful invocation ?
Yes, there is: ":set notimeout". To find such things, type ":set all",
this gives you some 40 settable options. Or read the manual.
> Why would vi want to check for typing speed (or skill)?
Most keyboards have a keys with arrows on them. They typically generate
some escape-sequence. Mine generate ^[OA for up, ^[OB for down, ^[OC
for left and ^[OD for right. You could try :map to see what vi thinks
your arrow keys are generating.
Hence if vi sees an escape, an O and an A all typed within 1 second, it
thinks I have hit the "up" key and moves the cursor up. If they do not
arrive within 1 second, vi thinks I have typed the keys separately and
interprets them as three commands.
If I :set notimeout then I can type the sequence esc O B very slowly and
the cursor goes down as if I had typed a down arrow. On the other hand,
if I type an escape, vi does not beep until I type another key. If the
next key is not an O, then vi beeps and obeys the key. If it is an O
then vi waits for a third key, before deciding whether or not it saw an
arrow key sequence.
Your :map command tells vi that you have a key generating the sequence
@s and vi is trying to distinguish that key from the @ command applied
to register s. Of course, you don't have such a key and you fake it by
typing fast enough. That'll work most of the time. And getting the
message "Nothing in register s" isn't that bad. But you had better not
put the string 1GdG in register s....
>Dolf Grunbauer
Hans Mulder ha...@cs.kun.nl
Dolf Grunbauer
I have defined some vi macros in my shell variable EXINIT. Some of them I
use to execute certain shell scripts like:
map @s :w
which checks the current file for spelling errors (of course I have used it
for this article :-)
Sometimes invocation of this macro (by typing @s in edit mode) fails with
the error: "Nothing in register s"
It seems to happen when there is too much time between typing the "@" and "s".
Is this true ? If so: what is the time limit ? Is there a bypass for always
successful invocation ? Why would vi want to check for typing speed (or skill)?
--
Dolf Grunbauer Tel: +31 55 433233 Internet do...@idca.tds.philips.nl
Philips Information Systems UUCP ...!mcsun!philapd!dolf
Dept. BS Software, P.O. Box 245, 7300 AE Apeldoorn, The Netherlands
read: error in reading .signature
Dan Mercer
:I have defined some vi macros in my shell variable EXINIT. Some of them I
Why are you trying to redefine the @ command? @s says take the text
stored in register s and execute it as a macro. The way vi macro
resolution works, if it matches on a key sequence, it will try
to complete that key sequence (using a one second alarm). If the timer
expires, the accumulated characters are processed as characters (thus
the message).
Why? Because vi is a gloriuos kludge. It is a visual interface to
the ex line editor (it is the same file linked 5 different ways).
Ex was designed before the advent of pf keys, and uses the escape
key to change states. When terminals became more advanced, gained
screen addressability, those new functions were implemented either
by use of control characters or escape sequences. Similarly, pf keys,
cursor keys and others were implemented as escape sequences.
Rather than fold these key sequences into vi proper, they were
implemented as macros (map will reveal their sequences). How then
to differentiate the escape that begins an escape sequence from one
that is used to change states? Timing.
The drawback is, sleep and alarm do not provide discrete 1 second
timers. Sleep(1) expires when the next one second timer on the system
expires, always less than one second and possibly even virtually no
time later. In fact, there used to be warnings against specifying
sleep (1) since the timer might have been exhausted before the sleep
completed and you never would come back. That bug has been fixed.
It could have been avoided if the key bindings were made dynamic -
but that would no longer be backward compatible.
You can disable the timeout by :set notimeout.
While this prevents timing out it can have bizarre side effects (having
to hit escape twice. Accidentally invoking pf keys. VT100 pf keys
begin \EO. If you enter escape to stop input on current line, then
start typing O and the first character on the above line, you may
actully complete a pfkey sequence. If that key is set to :q!, well.
too bad.
Why not set macro to \Eg - guaranteed to be safe.
--
Dan Mercer
Reply-To: mer...@ncrstp.StPaul.NCR.COM (Dan Mercer)