Re: Emacs design and architecture (was: Shrinking the C core)

[Eli Zaretskii]

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