Xref: utzoo comp.bugs.sys5:1322 comp.unix.i386:7340 comp.unix.questions:24156 comp.unix.xenix:12595 Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!mailrus!uunet!zephyr.ens.tek.com!tektronix!sequent!petebob From: petebob@sequent.UUCP (Pete_Bob Apple) Newsgroups: comp.bugs.sys5,comp.unix.i386,comp.unix.questions,comp.unix.xenix Subject: Re: Obscure Vi bug? Message-ID: <39591@sequent.UUCP> Date: 29 Jul 90 19:48:55 GMT References: <798@intelhf.hf.intel.com> <846@mwtech.UUCP> <618@tetrauk.UUCP> Reply-To: petebob@crg2.UUCP (Pete Apple) Organization: Sequent Computer Systems, Inc. Lines: 27 In article <618@tetrauk.UUCP> rick@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. From some investigation, this bug seems to be related to how the sys5 version of vi treats the p. It tosses the p, and inserts an 'a' into the command queue, to append the last buffer. Unfortunately, it seems the append that happens doesn't end after the buffer, and ends up appending the rest of your macro as well. Need an escape sequence in there to work around it. On our version of vi (at least), if you use the sequence xph, it works correctly. A hack, in the very least. Pete_Bob -- 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