Re: Emacs design and architecture (was: Shrinking the C core)

[Eli Zaretskii <eliz@gnu.org>]

> From: Richard Stallman <rms@gnu.org>
> Cc: owinebar@gmail.com, emacs-devel@gnu.org
> Date: Tue, 19 Sep 2023 06:22:36 -0400
> 
>   > In off-line discussions with Stefan Monnier, we both arrived at the
>   > conclusion that some basic limitations of the current display engine
>   > cannot be lifted without redesigning how buffer text is stored and
>   > accessed.
> 
> I agree they would require something more powerful than text
> properties and overlays as they are now.  Text properties were
> designed to work consistently with copying text between buffers and
> strings, and that imposed a limit.  What made this conceptually simple was
> the idea that each character individually has its own properties.
> 
> If we add a more powerful method of attaching non-text data to
> buffers, the design phase should include specifying precisely how they
> would behave when copying text between buffers and strings.

It isn't just about text properties and overlays.  Even simple C-n
requires us to march all the way between the position of point to the
position that's below it on the screen.  We must process each and
every buffer position in-between, and perform a large portion of what
redisplay does (specifically, its layout calculations, which require
the metrics of every character we traverse) to find the character that
is directly below point, so that we could move point there.  All this
because buffer text is a single unstructured string of bytes.  If we
want to speed up redisplay in such situations, we must get some help
from the buffer text itself, so as not to have to redo all those
layout calculations each and every time we need to convert buffer
positions to screen coordinates or back.