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

[Dmitry Gutov <dmitry@gutov.dev>]

On 15/09/2023 09:51, Yuri Khan wrote:
> 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. The styling
> engine does all the work about calculating the intermediate values and
> re-layouting each intermediate frame; the page author does not have to
> script carefully timed property changes, and is in fact discouraged
> from doing so because doing that in Javascript incurs CPU and battery
> usage overhead.

There are different ways to do it, but the classical correspondence to 
what pulse.el does is to use JavaScript, which would trigger on a timer 
and modify the DOM tree, exactly how pulse is triggered on a timer and 
updates the overlays in a buffer.

It's fast enough, and the JavaScript-based animations had reached more 
complexity than what we do with Emacs. It's just that the web sites have 
been getting more complex and complex over the years, that doing many of 
those animations is costly for battery and can bring the frame rate down 
(along with many other tabs being loaded at the same time). TBH, I can't 
think of many existing animations in Emacs that would be well-served by 
CSS animation instructions. Maybe just extra eye candy like exploding 
cursors.

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

That's also an option, but that seems to depart from making a good 
comparison between systems. It's not like anybody is thinking of 
implementing animation instructions in the display engine, are they?

The closest stuff to CSS that we have are stuff like 'display' and 
'invisible' properties, as well as display specs like :width, :align-to, 
:height and (slice ...).

> (Implementing a CSS engine over a character terminal is a nontrivial
> matter though.)

I don't know, if such engine is limited to a rectangular canvas of rows 
of characters, that would work more or less the same as it does not.