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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 15 Sep 2023 00:35:12 +0300
> Cc: rms@gnu.org, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 14/09/2023 19:52, Eli Zaretskii wrote:
> >> For the other, it sounds like you'd like to have more GUI primitive
> >> type operations available on the canvas directly, without having to
> >> use explicit GUI objects like child frames.
> > We cannot draw on the canvas directly without making the display
> > engine aware of what we are drawing and where, because the display
> > engine is responsible for updating the display when something changes.
> > So what we need is to be able to place a glyph using arbitrary 3D
> > coordinates (the 3rd coordinate for overlaying stuff on top of what's
> > already displayed), instead of having to work with rows of glyphs.
> > 
> > Again, studying what others do in this area would be useful, I think.
> 
> Perhaps the classic case is the Mozilla browser, which has from the 
> beginning implemented its browser UI (chrome) using an HTML-like 
> technology called XUL which also uses CSS and JavaScript for styling 
> (colors, size, alignment, positioning) and scripting. Except XUL 
> provided access to the platform widgets, graphical elements, menus, 
> dialogs, etc. Still, it's like a web page for displaying web pages, in a 
> sense.
> 
> Not sure how relevant that is for Emacs: doing a wrapper for an OS 
> toolkit is a lot of work.

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).  So I'm not sure CSS is the
right means for this job to begin with, although it perhaps could take
care of rarely-changing defaults.

Another thing to keep in mind is that there should be an efficient way
of telling the display back-end which portions of a window to redraw
given some changes in the text and display-related data structures.
(Of course, if the display back-end is so efficient that it can
redisplay everything fast enough, even if displaying across a network
on a different terminal, this aspect might be a non-issue.)