Xref: utzoo comp.bugs.sys5:1334 comp.unix.i386:7547 comp.unix.questions:24317 comp.unix.xenix:12658
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!pacbell.com!pacbell!att!ll1a!cuuxb!mmengel
From: mmengel@cuuxb.ATT.COM (~XT6561110~Marc Mengel~C25~M27~6184~)
Newsgroups: comp.bugs.sys5,comp.unix.i386,comp.unix.questions,comp.unix.xenix
Subject: Re: Obscure Vi bug?
Message-ID: <4886@cuuxb.ATT.COM>
Date: 3 Aug 90 21:51:15 GMT
References: <798@intelhf.hf.intel.com> <846@mwtech.UUCP> <618@tetrauk.UUCP> <rob.649040634@dutncp8>
Reply-To: mmengel@cuuxb.UUCP (Marc W. Mengel)
Followup-To: comp.bugs.sys5
Organization: AT&T National Technical Support Center
Lines: 28

In article <rob.649040634@dutncp8> rob@dutncp8.tudelft.nl (Rob Kurver) writes:
>In <618@tetrauk.UUCP> rick@tetrauk.UUCP (Rick Jones) writes:
>>  This happens in any macro using p or P
>>followed by other characters, all the subsequent characters get inserted, not
>>obeyed as commands.  
>I've experienced the same problem with the ESIX version of vi.  When used
>in a macro, p and P don't work correctly.


	Having hacked on vi in the past, I would suspect this is yet
	another buffer management bug; i.e. the buffer containing the
	macro is being labeled as the "current" buffer for the p command.

	You can *probably* work around this by using a named buffer, as
	in 

		"ayyj"ap

	instead of

		yyjp

	in your favorite macros, as the vi buffer code is notoriously 
	tough to make sense of...
-- 
 Marc Mengel					mmengel@cuuxb.att.com
 						attmail!mmengel
 						...!{lll-crg|att}!cuuxb!mmengel