Re: Emacs design and architecture. How about copy-on-write?

[Eli Zaretskii <eliz@gnu.org>]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: dmitry@gutov.dev, acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org
> Date: Thu, 21 Sep 2023 10:41:52 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I believe that it is more a question of rewriting text property handling
> >> into multiple segment trees dedicated to individual properties.
> >
> > Not as far as redisplay is concerned, no.  The display engine _wants_
> > to look for the next change in any text property, because it processes
> > them all "together".  That is, it finds the buffer position where any
> > of the text properties change, then hands that position to each of the
> > known methods for handling property changes so that each one of them
> > does its thing.
> 
> This is... not what I know. May you please point me where in the code it
> is done?

compute_stop_pos finds the next "stop position" where properties (or
something else of interest to redisplay) change, and when the
iteration gets to that position, handle_stop calls the available
handler methods to do their thing.  The intervals of the text
properties are examined by compute_stop_pos.

> >From my previous experience, there separate processing of invisible
> property and separate processing of composition property. But not
> generic processing looking into all present text properties, including
> the ones unrelated to redisplay.

All of the handlers are called one after the other on every stop
position we process.  So the processing is sequential, but not
"separate".  In particular, the higher-level iteration routine
(get_next_display_element), which detects when a stop position was
reached, doesn't know and doesn't care which text property triggered
the stop position; each called method checks if the current iteration
position needs it to do something, and if not, immediately returns.
That's how we support several properties that change at the same
buffer position.