Obscure Vi bug?

[Mike Rubin]

In article <846 at mwtech.UUCP> martin at mwtech.UUCP (Martin Weitzel) writes:
>In article <798 at intelhf.hf.intel.com> fredch at 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 at attunix.att.com, address changing soon>