Obscure Vi bug?
Pete_Bob Apple
petebob at sequent.UUCP
Tue Jul 31 17:41:54 AEST 1990
In article <618 at tetrauk.UUCP> rick at tetrauk.UUCP (Rick Jones) writes:
>
>On this subject, this version has another annoying bug, involving the use of p
>or P in macros. E.g. I use a key mapping to swap adjacent characters, which is
>the sequence xph (the h keeps the cursor in the same position). As a macro,
>the h gets inserted into the text! This happens in any macro using p or P
>followed by other characters, all the subsequent characters get inserted, not
>obeyed as commands. Lots of macros won't work because of this, including the
>wonderful word-completion macro recently posted in comp.editors.
>
>Is this unique to the SCO version of vi? And will someone at SCO please fix
>it.
>
I've got a fix for those of you out there that might have source to modify.
The fix is in the file ex_vget.c, in the getbr() function. Basically, the
order in which the various strings are searched for input needs to be reordered.
If you take a look at the file, you'll notice it looks for input from
a few different buffers before going out to read something new.
The bug occurs because when the p command goes to read the characters
to "put", it ends up reading in the rest of the macro before the input
characters themselves.
This is the current order of the buffers searched:
if (Peekkey) { ... } /* Peek ahead buffer */
if (vmacp) { ... } /* Macro string buffer */
if (Peek2key) { ... } /* 2nd Peek ahead buffer*/
if (vglobp) { ... } /* New text to insert */
The fix is to change the order like so:
if (Peekkey) { ... } /* Peek ahead buffer */
if (Peek2key) { ... } /* 2nd Peek ahead buffer*/
if (vglobp) { ... } /* New text to insert */
if (vmacp) { ... } /* Macro string buffer */
This bug exists in V.3.2, and V.4 as well.
--
Pete_Bob Apple Sequent Computer Systems
sequent!petebob 15450 S.W. Koll Parkway
Bob is not just a name.. Beaverton, Oregon 97006
It's a way of life.. (503) 626-5700
More information about the Comp.unix.xenix
mailing list