Re: Emacs design and architecture

[Gerd Möllmann]

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 :-(.