[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Future of display engine and lines

From: Richard Stallman
Subject: Re: Future of display engine and lines
Date: Sun, 24 Oct 2021 22:18:40 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

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

  > Perhaps I misunderstand what "multiple columns" mean, then.  Doesn't
  > it mean that buffer text is displayed in separate rectangular
  > portions, like this:

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

                         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 suppose that these two columns actually start 5 libes above
aaaaaaaaaaaa and xxx, and those lines are scrolled off the top of the
window.  This means that xxx does not follow kkkk in the buffer text.
Rather, kkkk is followed by some more lines below (off the window below)
and a few more lines that are above xxx... (off the window above).

In that case point A is at the start of the five lines above aaaaaaaaaaaa,
abd point B is at the start of the five lines above xxx.

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

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

Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]