🚀 go-pugleaf

In article <798@intelhf.hf.intel.com> fredch@starlite.hf.intel.com () writes:
>Has anyone else experienced this?  I have AT&T/Intel Unix V/386 on my box:
>
>Take a 50 line file (not sure if 50-line specific
        ^^^^^^^^^^^^
>Go to 2 lines below the bottom line using the G command.  For example, under
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>TERM=xterm, go to line 25; under TERM=AT386 or TERM=vtpc, go to line 26.
                   ^^^^^^^                                       ^^^^^^^^
>Then type ^B.  It will beep.  Then, type j.  Suddenly the current line will
>be copied onto line 1, and your file just got modified.
>-- 
Fred,
	What are you talking about?????  If you can go to 2 lines below
	the bottom of the file with a G command, you found a bug there!
	If two lines below the bottom of the file can be either line 25
	or 26 of a 50 line file you found ANOTHER bug.

	Sit back, take a deep breath and try all this again.
-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|Disclaimer:                      | James Cummings                           |
|  You can't blame me!            |   UUCP:                                  |
|  I'm ignorant!                  |    ..swblat!{texbell!texnet..            |
|+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+|              swgate!dlss1..}!dlss2!james |
|Send flames to:                  |   NET:                                   |
|  sowc@devnull.com               |      jc@smunews                          |
|                                 |                                          |
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

In article <798@intelhf.hf.intel.com> fredch@starlite.hf.intel.com () writes:
>Has anyone else experienced this?  I have AT&T/Intel Unix V/386 on my box:
>
>Take a 50 line file (not sure if 50-line specific, but that's where I found it).
>Go to 2 lines below the bottom line using the G command.  For example, under
>TERM=xterm, go to line 25; under TERM=AT386 or TERM=vtpc, go to line 26.
>Then type ^B.  It will beep.  Then, type j.  Suddenly the current line will
>be copied onto line 1, and your file just got modified.

Just tried this with ISC 386/ix 2.0.2 and SCO XENIX V. Same bug here.
I produced it in the following way:

1) Take a file somewhat larger than your screen (50 lines are not
   critical)
2) Make line "LINES+1" to be shown in the last line of your screen.
   Use any command you like to do so, move the cursor to any place
   you like, after you have positioned the screen.
   (Note: LINES defaults to 25 for TERM=AT386; so line 26 schould
   be last on the screen. You may verify this by ":set nu")
3) Type ^B (CTRL-B) ==> terminal beeps; screen *doesn't* change
4) Type ^L (Redraw screen) ==> Screen changes, topmost line is 1 now!
5) Type ^L once more ==> first line of screen changes and shows the
   same as the line your cursor were in when you typed ^B in step 3)

I hope somebody who can fix this bug will read this description.

	***********************************************
	**           ALL OTHERS BE WARNED:           **
	**                                           **
	** USING CTRL-B IN vi MAY RESULT IN CHANGING **
	**   YOUR FILE UNDER CERTAIN CIRCUMSTANCES!  **
	***********************************************

Note: I've crossposted this to several other groups where the
readers might be interested in this warning. Furthermore I'm not
at all sure if this bug is specific to SysV.
-- 
Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83

From article <798@intelhf.hf.intel.com>, by fredch@starlite.hf.intel.com:
> Has anyone else experienced this?  I have AT&T/Intel Unix V/386 on my box:
> 
> Take a 50 line file (not sure if 50-line specific, but that's where I found it).
> Go to 2 lines below the bottom line using the G command.  For example, under
> TERM=xterm, go to line 25; under TERM=AT386 or TERM=vtpc, go to line 26.
> Then type ^B.  It will beep.  Then, type j.  Suddenly the current line will
> be copied onto line 1, and your file just got modified.

This also occurs with the vi on SCO UNIX V3.2.0, which, when given the
:version command reports SVR3.1.  It doesn't appear to be file length
specific.
-- 
Roger A. Cornelius          rac@sherpa.UUCP         uunet!sherpa!rac

In article <798@intelhf.hf.intel.com> fredch@starlite.hf.intel.com () writes:
>Has anyone else experienced this?  I have AT&T/Intel Unix V/386 on my box:
>
>Take a 50 line file (not sure if 50-line specific, but that's where I
>found it).  Go to 2 lines below the bottom line using the G command.
>For example, under TERM=xterm, go to line 25; under TERM=AT386 or
>TERM=vtpc, go to line 26.  Then type ^B.  It will beep.  Then, type j.
>Suddenly the current line will be copied onto line 1, and your file
>just got modified.

I see exactly the same thing on 386/ix Version 2.0.2.  Vi is Version
SVR3.1.  Also vi also often returns a nonzero status, despite the fact
that nothing seems to have gone wrong.


Many Thanks:	

Jonathan Ryshpan		<...!uunet!hitachi!jon>

M/S 420				(415) 244-7369  	
Hitachi America Ltd.
2000 Sierra Pt. Pkwy.
Brisbane CA 94005-1819

In article <846@mwtech.UUCP>, martin@mwtech.UUCP (Martin Weitzel) writes:
= In article <798@intelhf.hf.intel.com> fredch@starlite.hf.intel.com () writes:
= >Has anyone else experienced this?  I have AT&T/Intel Unix V/386 on my box:
= >
= >Take a 50 line file (not sure if 50-line specific, but that's where I found it).
= >Go to 2 lines below the bottom line using the G command.  For example, under
= >TERM=xterm, go to line 25; under TERM=AT386 or TERM=vtpc, go to line 26.
= >Then type ^B.  It will beep.  Then, type j.  Suddenly the current line will
= >be copied onto line 1, and your file just got modified.
= 
= Just tried this with ISC 386/ix 2.0.2 and SCO XENIX V. Same bug here.
= I produced it in the following way:
= 
[... detailed description of how to reproduce bug ...]

I tried it on several machines with several 24 and 25 line terminals.
I could not reproduce the bug. As all these systems are BSD or -related,
it seems that the bug is specific to the SYS V version of vi.

	-mg
-- 
 .-. .-.  .-.  Michael Greim
(   X   )( __) e-mail : greim@cs.uni-sb.de
 \ / \ /  \ /  or     : ...!uunet!unido!sbsvax!greim
  ~   ~    ~

In article <846@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes:
>In article <798@intelhf.hf.intel.com> fredch@starlite.hf.intel.com () writes:
>>Has anyone else experienced this?  I have AT&T/Intel Unix V/386 on my box:
>>
>>Take a 50 line file (not sure if 50-line specific, but that's where I found it).
>>Go to 2 lines below the bottom line using the G command.  For example, under
>>TERM=xterm, go to line 25; under TERM=AT386 or TERM=vtpc, go to line 26.
>>Then type ^B.  It will beep.  Then, type j.  Suddenly the current line will
>>be copied onto line 1, and your file just got modified.
>
>Just tried this with ISC 386/ix 2.0.2 and SCO XENIX V. Same bug here.
>I produced it in the following way:
>
>1) Take a file somewhat larger than your screen (50 lines are not
>   critical)
>2) Make line "LINES+1" to be shown in the last line of your screen.
>   Use any command you like to do so, move the cursor to any place
>   you like, after you have positioned the screen.
>   (Note: LINES defaults to 25 for TERM=AT386; so line 26 schould
>   be last on the screen. You may verify this by ":set nu")
>3) Type ^B (CTRL-B) ==> terminal beeps; screen *doesn't* change
>4) Type ^L (Redraw screen) ==> Screen changes, topmost line is 1 now!
>5) Type ^L once more ==> first line of screen changes and shows the
>   same as the line your cursor were in when you typed ^B in step 3)
>
>I hope somebody who can fix this bug will read this description.

I have reproduced it in the current development load of AT&T SVR4.0/386
version 2.0.  I'll file the trouble report; it may or may not get fixed
in time for the next customer release.

--Mike Rubin	<mike@attunix.att.com, address changing soon>

	Yes, this appears to be a bug in vi.  I get the same results,
now that I understand the problem. 

	If a set report=1 is done there is not even a notification that
any line has been changed.

	Enviornment:
		System V r 3.2.1
		AT&T 3B2/700

		Output from "what" for vi:
  /usr/bin/vi:
   	   printf.c:2.2 6/5/79
	   /usr/bin/vi.sl 1.31 3.2 01/06/88 16362 AT&T-SF


-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|Disclaimer:                      | James Cummings                           |
|  You can't blame me!            |   UUCP:                                  |
|  I'm ignorant!                  |    ..swblat!{texbell!texnet..            |
|+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+|              swgate!dlss1..}!dlss2!james |
|Send flames to:                  |   NET:                                   |
|  sowc@devnull.com               |      jc@smunews                          |
|                                 |                                          |
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Another bug in 'vi' relates to the use of uparrow to switch to another
file. If it fails for any reason, it will do weird things. It might be
as benign as throwing you into line mode (repeat by: starting in a modified
file, ":f non-existent-file" then "^^") or erasing the current line. That
one I can't create on demand, but it's happened several times.
-- 
Peter da Silva.   `-_-'
+1 713 274 5180.   'U`
<peter@ficc.ferranti.com>

In article <92@dlss2.UUCP> james@dlss2.UUCP (James Cummings) writes:
>	What are you talking about?????  If you can go to 2 lines below
>	the bottom of the file with a G command, you found a bug there!
>	If two lines below the bottom of the file can be either line 25
>	or 26 of a 50 line file you found ANOTHER bug.

I think he meant position the cursor on the second line below the bottom
line displayed on the screen; therefore, on a 24 line screen, "vi" uses
a 23 line window for displaying the file, and the 25th line is the second
line below the 23rd.

This bug both exists in SVR3.2 and SVR4.  It's quite a disaster, isn't it?
-- 
- Matthew T. Day, Sanyo/ICON, mday@iconsys.icon.com || uunet!iconsys!mday

In article <462@hitachi.uucp>, jon@hitachi.uucp (Jon Ryshpan) writes:
> [ ... ]    Vi is Version
> SVR3.1.  Also vi also often returns a nonzero status, despite the fact
> that nothing seems to have gone wrong.

Some versions of vi [I don't know exactly which ones, but they
include the one on cbnewsm  :-( ] apparently count failed searches
and 'f', 't', etc., commands that you issued.

For example, if you edit a file, do three searches that return
"Pattern not found", then exit, vi will have a return code of 3.

For my own sanity, I have a shell called "vi" in my bin that runs
the /usr/bin/vi and then does an exit 0.  That way I don't get
"couldn't run editor" messages when I try to post something like
this.

 -- Speaking strictly for myself,
 --   Lee Derbenwick, AT&T Bell Laboratories, Warren, NJ
 --   lfd@cbnewsm.ATT.COM  or  <wherever>!att!cbnewsm!lfd

I've seen a similar problem running vi under SunOS 4.1.  (SunOS 4.1 is
shipped with some System-V version of vi).  The display of lines gets
scrambled, the file isn't actually changed, ctrl-L redraws the screen
to exactly the same confused state, but strangely enough, ctrl-G will
fix the display.
--
Felix Lee	flee@cs.psu.edu

>I've seen a similar problem running vi under SunOS 4.1.  (SunOS 4.1 is
>shipped with some System-V version of vi).

System V Release 3.1, with assorted fixes to some bugs found at Sun
(most of which, as I remember, were also in the 4.[23]BSD one), tag
stack stuff added, and "modelines" renamed back to "modeline",
4.xBSD-style. 

Well, gee, as long as we're gonna pour out some vi bugs..

On (at least) SysVr3.1 and r3.2 on the 3b2 line if you use
the '!' command to filter some text, then a zombie is left around.
You do that enough times and you fill up the process table with
zombies and somebody comes to your cubicle and asks what's going
wrong with the system.  At least that's what happened to me the
time I was playing with some tables of information for which
I had an awk(1) script which recalculated the tables...

Short-Version: The filter command in vi leaves a zombie hanging.

Fix: Do a wait(2), silly!
-- 
<- David Herron, an MMDF weenie, <david@twg.com>
<- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu>
<-
<- Sign me up for one "I survived Jaka's Story" T-shirt!

In article <92@dlss2.UUCP> james@dlss2.UUCP (James Cummings) writes:
>	What are you talking about?????  If you can go to 2 lines below
>	the bottom of the file with a G command, you found a bug there!

Obviously by "bottom line" he meant "bottom of the display".
This was evident from the example he gave.

In article <846@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes:
>In article <798@intelhf.hf.intel.com> fredch@starlite.hf.intel.com () writes:
>>Has anyone else experienced this?  I have AT&T/Intel Unix V/386 on my box:
>>
>>Take a 50 line file (not sure if 50-line specific, but that's where I found it).
>>Go to 2 lines below the bottom line using the G command.  For example, under
>>TERM=xterm, go to line 25; under TERM=AT386 or TERM=vtpc, go to line 26.
>>Then type ^B.  It will beep.  Then, type j.  Suddenly the current line will
>>be copied onto line 1, and your file just got modified.
>
>Just tried this with ISC 386/ix 2.0.2 and SCO XENIX V. Same bug here.

I can confirm this happens with SCO Unix, too (ODT version, at least).

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.

-- 
Rick Jones					You gotta stand for something
Tetra Ltd.  Maidenhead, Berks			Or you'll fall for anything
rick@tetrauk.uucp (...!ukc!tetrauk.uucp!rick)	     - John Cougar Mellencamp

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.

Same on ISC 386/ix 2.0.2 as I just tried. Strange enough that p and P
work if they are the last command character of a mapped sequence. For
any particular problem one may try to change the sequence so that the
p or P appears last, like lxhhp which gives you what you expect from xph,
but in general it's annoying.

One more of these things (which I don't consider a real bug, as the
topics this thread started with, but rather a "anomality").

The commands d, c, y, <, >, and ! require a following move. Has
anybody allready noticed that this seems all fine but there's
an inconsitency with a w-move vs. the e-move in the context of
the c-command? Though e and w move to different places and do
something different in case of the de- and ye-command, they behave
the same when combined with the c-command. Shouldn't cw include the
blanks after the word and only ce behave the way most of us know
from cw. (Yes, it would be inconvienient to change habits, but it's
not "logical" how it is now.)

P.S. Wouldn't it be a nice idea to archive these "anomalities" somewhere.
(Volunteers? Oh what a silence around - I could hear a penny fall ... :-))
-- 
Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83

In <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.

I've experienced the same problem with the ESIX version of vi.  When used
in a macro, p and P don't work correctly.

--
Rob Kurver                          rob@dutncp8.tudelft.nl
Computational Physics Group         rob@pact.nl
Faculty of Applied Physics, Delft University of Technology

Learning French is trivial: the word for horse is cheval, and
everything else follows in the same way.
		-- Alan J. Perlis

In article <295@sherpa.UUCP> rac@sherpa.UUCP (Roger Cornelius) writes:
+---------------
| From article <798@intelhf.hf.intel.com>, by fredch@starlite.hf.intel.com:
| > Go to 2 lines below the bottom line using the G command.  For example, under
| > TERM=xterm, go to line 25; under TERM=AT386 or TERM=vtpc, go to line 26.
| > Then type ^B.  It will beep.  Then, type j.  Suddenly the current line will
| > be copied onto line 1, and your file just got modified.
| 
| This also occurs with the vi on SCO UNIX V3.2.0, which, when given the
| :version command reports SVR3.1.  It doesn't appear to be file length
| specific.
+---------------

This does *not* fail on an SGI 4D/25 (Irix 3.3). I tried "G"ing to +0, +1,
+2, +3 lines below the bottom one on the screen; "^B" always worked properly
from there, no beeps, no altering of text.

The ":version" command reports "Version SVR3.1". I don't know if the fix is
local to SGI, or possibly the bug is only in '386 versions of System-V.


-ROb

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com		rpw3@pei.com
Silicon Graphics, Inc.		(415)335-1673		Protocol Engines, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311

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 xp<ESC>h, 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

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.
>

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

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

In article <618@tetrauk.UUCP> rick@tetrauk.UUCP (Rick Jones) writes:
>In article <846@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes:
>>In article <798@intelhf.hf.intel.com> fredch@starlite.hf.intel.com () writes:
>>>Has anyone else experienced this?  I have AT&T/Intel Unix V/386 on my box:
>>>
>>>Take a 50 line file (not sure if 50-line specific, but that's where I found it).
>>>Go to 2 lines below the bottom line using the G command.  For example, under
>>>TERM=xterm, go to line 25; under TERM=AT386 or TERM=vtpc, go to line 26.
>>>Then type ^B.  It will beep.  Then, type j.  Suddenly the current line will
>>>be copied onto line 1, and your file just got modified.
>>
>>Just tried this with ISC 386/ix 2.0.2 and SCO XENIX V. Same bug here.
>
>I can confirm this happens with SCO Unix, too (ODT version, at least).
>

I've a fix for this bug too, if you have vi source to recompile.
In V3.2 and V.4, the source for vi, the file ex_vmain.c:

----------------------------------------------
Change this:
                /*
                 * ^B           Window backwards, with 2 lines of continuity.
                 *              Inverse of ^F.
                 */
                case CTRL('b'):
                        vsave();
                        if (one + vcline != dot && vcnt > 2) {
>                                addr = dot - vcline - 2 - (cnt-1)*basWLINES;
                                forbid (addr <= zero);
                                dot = addr;
                                vcnt = vcline = 0;
                        }
                        vzop(0, 0, '^');
                        continue;

----------------------------------------------
To:
                /*
                 * ^B           Window backwards, with 2 lines of continuity.
                 *              Inverse of ^F.
                 */
                case CTRL('b'):
                        vsave();
                        if (one + vcline != dot && vcnt > 2) {
>                                addr = dot - vcline + 2 - (cnt-1)*basWLINES;
                                forbid (addr <= zero);
                                dot = addr;
                                vcnt = vcline = 0;
                        }
                        vzop(0, 0, '^');
                        continue;
----------------------------------------------

This fix makes CTRL-b operate correctly, and the bug goes away.  I compared
with the BSD world, and this fix was already in there.  

-- 
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