Re: Future of display engine and lines

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: larsi@gnus.org, galex-713@galex-713.eu, emacs-devel@gnu.org
> Date: Sun, 24 Oct 2021 22:18:40 -0400
> 
>   >    aaaaaaaaaaaa bbbbbbbb ccccccc    xxx xxxxxxxx xxxxxxxxxxxx
>   >    dddddddd eeeeeeee fffffff ggg    yyyyyy yyyyyyyyy yyyyyyyy
>   >    hhhhhhhh iiiiiiiiii jjjj kkkk    zzzzzzzzz zzzzzzzzzz zzzz
> 
>   > where buffer position of the first "xxx" follows the buffer position
>   > of the last "kkkk"?
> 
> That's exactly what I had in mind.  But we should not assume that xxx
> are consecutive with kkkk.  We could be looking at the middle, vertically,
> of the two columns; their top and bottom could be off-screen.

Why would that make sense?  You will be unable to read the text
without scrolling the window.

> 
>                          If so, where in the above picture are your points
>   > A and B?
> 
> IF xxx immediately follows kkkk, then point A is at the start of aaaaaaaaaaaa
> and point B is at the start of xxx.

But then what did you mean by this:

  > > It could have multiple segments for each display line, and fill up
  > > one series of segments going vertically down from point A,
  > > then the next series of segments going vertically down from point B,
  > > and so on.

The "going vertically from A, then vertically from B" is the part I
don't understand: what did you mean by "fill up segments by going
vertically" here?

>   > Actually, I believe that any significant improvement in the Emacs
>   > display engine would almost certainly need a redesign of the buffer
>   > text data structure, because most current limitations of redisplay
>   > basically follow from the fact that buffer text is a single
>   > unstructured stream of bytes
> 
> I can't prove we don't need to do that, but I really hope so.
> Changing the display structure would be a rather local change,
> while changing the buffer format would be enormous.

Why enormous?  The internals of buffer text are known to relatively
small number of low-level primitives.

Making buffer text smarter than a linear byte stream could allow us to
know where to jump if the user moves point from "kkk" to the right,
with the intent of going to "zzzzzzzzzz", without costly scanning of
the buffer while simulating display.

IOW, I believe that leaving the buffer text design intact will make
redisplay that is already relatively slow in complex situations even
slower.  That is no way to move Emacs into the future.

> I have hope it will be possible to do this without changing the buffer
> format, so I suggest trying that first.

Well, for starters, how would you record the starting point of the
visible portion of each column? wouldn't that already need some change
in the window object, if not in the buffer text?