[Top][All Lists]

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

Re: Emacs design and architecture

From: Gerd Möllmann
Subject: Re: Emacs design and architecture
Date: Mon, 18 Sep 2023 08:36:50 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

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):


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.

reply via email to

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