Re: Emacs design and architecture

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>>
>>> This of course, would pose several problems.
>>>
>>> - This form of parallel redisplay cannot call Lisp, so no jit-lock, no
>>>   hooks, or whatever during redisplay.  And at the point where we call
>>>   redisplay today we don't know what will be displayed...
>>> - Parallel redisplay also needs either a copy of what it to be
>>>   displayed, or the model must be some persistent data structure
>>>   that makes immutable versions of buffer-text, for instance,
>>>   available.
>>
>> Some more idle musings:
>>
>> Let's say persistent data structures for buffer-text, overlays, text
>> properties and maybe other things are out of question because of the
>> effort involved.
>>
>> Another idea would be to produce, where we currently run redisplay, a
>> "model" that can be processed concurrently.  One could just guess how
>> much text will be displayed, run Lisp code as necessary (jit-lock), skip
>> invisble text, and so on, so that the parallel redisplay doesn't have
>> the need to call Lisp.  For simplicity, think of that new form of model
>> as HTML.
>>
>> That could be so slow that parallelism is not a win.
>>
>> What about the move_.* functions used by Lisp (vertical-motion, ...)?
>> To what degree does backward compatibily restrict what can be done in
>> the first place?  I'm beginning to think it sets quite harsh limits.
>>
>> Doesn't look good to me :-(.
>
> Here are some things I found wrt to buffer-text implementation.
>
> A ninteresting paper about text representations in general:
> https://www.cs.unm.edu/~crowley/papers/sds.pdf
>
> Piece tables:
> https://www.averylaird.com/programming/the%20text%20editor/2017/09/30/the-piece-table
>
> An implementation:
> https://github.com/cdacamar/fredbuf
>
> Something like that could be an inspiration for a persisten buffer-text
> implementation, which I think would be a prerequisite for a parallel
> redisplay.  (I don't believe in the idea of a snapshort model for parallel
> redisplay anymore).  This would not solve overlays, text properties
> and what not, of course.

And a bit more:

This is an interesting article about VSCode's buffer implementation,
which was changed from a line-based representation to a piece tree
(don't know if persistent or not):

https://code.visualstudio.com/blogs/2018/03/23/text-buffer-reimplementation

In summary, I think that, for a parallel redisplay in Emacs, a persistent
piece tree would probably a good choice, and it is doable.  From a
performance aspect, the Monaco editor (see link above) seems to show
that it's not too bad.

Overlays, text properties, calls to Lisp etc. remain open aspects.