[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dmitry Gutov
Subject: Re: Emacs design and architecture (was: Shrinking the C core)
Date: Fri, 15 Sep 2023 18:10:50 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]