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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> > 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.
>> 
>> Thanks!
>> "stop position" is not triggered by _all_ the properties though.
>> `compute_stop_pos' calculates the largest region where the properties
>> listed in `it_props' ('fontified, 'face, 'invisible, and 'composition)
>> remain the same. If any other property not in the list changes, it is
>> ignored (except `char-property-alias-alist' which may link other
>> properties to 'fontified/face/invisible/composition).
>
> Does this contradict what I wrote? if so, how?

Does not contradict, but adds some details. IMHO, it is important that
not _a_ property should change to "stop". But one of a small set of
properties.

I did not write this to argue about your statement. Just to get a reply
if I missed something when reading the code.

>> Further, handle_stop handlers do search for their corresponding handled
>> property via Fnext_single_property_change, which again iterates over
>> every interval in the buffer until that single property value changes.
>
> If they do this, it's because they need that to do their thing.
> There's no requirement from the handlers to do that.  Moreover, we
> could record the position of the next change of each property, when
> the handler does determine that, and use that in compute_stop_pos, to
> avoid repeating the same search.

That might indeed be one possible optimization.

>> I believe that having a more efficient algorithm to detect where a
>> single property change should speed things up significantly. handle_stop
>> will benefit directly, while `compute_stop_pos' could query
>> min (mapcar (Fnext_single_property_change, it_props))
>> to avoid counting unrelated properties.
>
> Feel free to present such a more efficient algorithm, and thanks.
> And I'm not sure I understand why you think that
>
>   min (mapcar (Fnext_single_property_change, it_props))
>
> will be cheaper than the current algorithm in compute_stop_pos, since
> Fnext_single_property_change basically examines the same intervals
> again and again for each property in it_props.

The algorithm I have in mind is to change interval tree to store several
trees together - a common tree storing segments delimited by _a_
property change + a tree for individual properties. That way, looking up
for next single property change will be a simple call to next_interval for
the property itself + property aliases.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>