|
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 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.
[Prev in Thread] | Current Thread | [Next in Thread] |