[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.
- Re: Emacs design and architecture, (continued)
- Re: Emacs design and architecture, Dmitry Gutov, 2023/09/17
- Re: Emacs design and architecture, Po Lu, 2023/09/17
- Re: Emacs design and architecture, Dmitry Gutov, 2023/09/18
- Re: Emacs design and architecture, Po Lu, 2023/09/18
- Re: Emacs design and architecture, Dmitry Gutov, 2023/09/18
- Re: Emacs design and architecture, Richard Stallman, 2023/09/17
- Re: Emacs design and architecture, Dmitry Gutov, 2023/09/18
- Re: Emacs design and architecture, Richard Stallman, 2023/09/17
- Re: Emacs design and architecture, Emanuel Berg, 2023/09/16
- Re: Emacs design and architecture, Gerd Möllmann, 2023/09/16
- Re: Emacs design and architecture,
Gerd Möllmann <=
- Re: Emacs design and architecture, Helmut Eller, 2023/09/17
- Re: Emacs design and architecture, Eli Zaretskii, 2023/09/17
- Re: Emacs design and architecture, Gerd Möllmann, 2023/09/18
- Re: Emacs design and architecture (was: Shrinking the C core), Dmitry Gutov, 2023/09/15
- Re: Emacs design and architecture (was: Shrinking the C core), Dmitry Gutov, 2023/09/15
- Re: Emacs design and architecture (was: Shrinking the C core), Richard Stallman, 2023/09/16
- Re: Emacs design and architecture (was: Shrinking the C core), Eli Zaretskii, 2023/09/17
- Re: Emacs design and architecture (was: Shrinking the C core), Richard Stallman, 2023/09/19
- Re: Emacs design and architecture (was: Shrinking the C core), Eli Zaretskii, 2023/09/19
- Re: Shrinking the C core, Emanuel Berg, 2023/09/13