Re: Emacs design and architecture

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Yuri Khan <yuri.v.khan@gmail.com>
>> Date: Fri, 15 Sep 2023 13:51:56 +0700
>> Cc: Dmitry Gutov <dmitry@gutov.dev>, owinebar@gmail.com, rms@gnu.org, emacs-devel@gnu.org
>> 
>> On Fri, 15 Sept 2023 at 12:51, Eli Zaretskii <eliz@gnu.org> wrote:
>> 
>> > One of the important aspects to keep in mind in this regard is that
>> > Emacs must give Lisp programs dynamic control of how stuff is
>> > displayed, and should be able to exercise that control at high
>> > frequency (a trivial example: pulse.el).
>> 
>> In CSS, this is solved in core with transitions. A style specifies
>> that a certain property will change gradually, provides its target
>> value, the transition duration, and a transition curve.
>
> You have taken the pulse.el example too literally.  The fact that it
> changes the color gradually is not relevant to the point I was trying
> to make, but you made it the main point.
>
> My point is that quite a few Lisp programs affect the display in
> near-real time and at high frequency.  This is what makes Emacs so
> powerful, and we don't want to lose this power when changing the
> display engine.
>
>> The use case of pulse.el would be translated to a couple of styles
>> that say effectively “A pulsed span will instantly gain yellow
>> background” and “A non-pulsed span will linearly revert to whatever
>> background it had over the course of 200 milliseconds” and a small
>> function that sets the span to pulsed and then immediately to
>> non-pulsed.
>
> This sounds like a lot of hair, when a Lisp program just wants to
> change the color of some part of the display.
>
>> (Implementing a CSS engine over a character terminal is a nontrivial
>> matter though.)
>
> Something else to keep in mind, I guess.  TTY colors are implemented
> specially and separately in Emacs (under the hood; Lisp programs can
> disregard the differences if they want), so it isn't a non-starter,
> per se.

I think it would maybe be good to think about the following:

Random thoughts about a parallel redisplay, from a height of 10 km.

What currently happens to bring changes to the screen is that redisplay
is called quite frequently in the course of processing input for
example.  Redisplay determines what part of the a "model" (buffer) has
changed, if any.  It makes sure that all info it needs to proceed is
available; think jit-lock, i.e. it calls Lisp. Because redisplay is
called frequently, it must minimize what it does, which is the reason
for the complicated optimizations there.

Whatever is done in the end, I think it would first be necessary to
change this general principle, so that layout/drawing whatever can
happen in parallel.  Without that, I suspect redisplay would get too
slow, or would finally collapse to a black hole by its complexity.

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.