Slightly obscure "framer" lossage

[Doug Dodds <DODDS at SCRC-TENEX>]

    Date: Friday, 20 July 1984, 14:49-EDT
    From: David A. Moon <Moon at SCRC-TENEX>

	Date: Friday, 20 July 1984, 03:40-EDT
	From:  <TIM at MIT-MC>

	In ZWEI in Release 5.1, Experimental MIT 1.4, FEP 18, on Lisp Machine 
	Jimi Hendrix (3600):

	When an editor line occupies more than one physical line on the screen
	(i.e. wraps around) and the cursor is anywhere other than on the first
	physical line of that editor line, the redisplayer's framer loses...

    Thanks for the report.  I fixed this in the development system when it
    was first reported.  I believe the fix is included in Release 5.2,
    currently in QA, although I did not actually go and verify the truth of
    that statement.

Oops, not quite fixed, it appears.  I am running 249.77 right now; I
think the following observations probably apply to 5.2 also.  It is true
that this situation (an editor buffer of more than one frame, the
present frame contains a line that wraps) now doesn't always lose.  For
instance, position the cursor to some point in the second physical line
of the very long line, and type c-0 c-L.  The frame will then be
positioned with the -physical- line in which the cursor sits at the top.
(Side question: is this right, or should all of the buffer line that
contains the cursor be in the frame, if possible?)

However, position the cursor the same as above, but insert some
characters.  Now do c-0 c-L, and the frame will be adjusted as if you
typed c-L.  Do it again, and now the cursor line will go to the top, but
only if the frame moved (somehow) on the previous framing command.  So
if you center the line of interest (c-L) and then insert some
characters, any number of c-0 c-L commands will not move it!  It will
only reframe if you do c-L and then c-0 c-L.  So not everything is quite
straight yet.