emacs-devel
[Top][All Lists]
Advanced

[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: Sun, 17 Sep 2023 09:34:27 +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:
>
>> 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.



reply via email to

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