Re: Emacs design and architecture

[Dmitry Gutov <dmitry@gutov.dev>]

On 15/09/2023 22:19, Gerd Möllmann wrote:
> Eli Zaretskii<eliz@gnu.org>  writes:
> 
>>> From: Gerd Möllmann<gerd.moellmann@gmail.com>
>>> Cc: Eli Zaretskii<eliz@gnu.org>,  Yuri Khan<yuri.v.khan@gmail.com>,
>>>    owinebar@gmail.com,rms@gnu.org,emacs-devel@gnu.org
>>> Date: Fri, 15 Sep 2023 20:36:07 +0200
>>>
>>> Maybe it would be worth looking at emacs-ng
>>>
>>>    https://github.com/emacs-ng/emacs-ng
>>>
>>> The README lists the feature
>>>
>>>    Webrender
>>>
>>>    WebRender is a GPU-based 2D rendering engine written in Rust from
>>>    Mozilla. Firefox, the research web browser Servo, and other GUI
>>>    frameworks draw with it. emacs-ng use it as a new experimental graphic
>>>    backend to leverage GPU hardware.
>> I didn't look at this, but if by "graphic backend" they mean a
>> replacement for xterm.c, then this is much less interesting, because
>> the basic limitations of the current display engine's layout and
>> iterator (which are all implemented in xdisp.c and dispnew.c) will
>> still be with us.
> I've cloned the repo now, and it seems indeed to be a backend like xterm
> or nsterm etc.  It's called wrterm, and is implemented in ca. 8.5 kloc
> of Rust.  I can't read Rust fluently, but I'd say It implements the
> usual functions for such a backend and not more.
> 
> So, I agree, that's not very interesting in this context.

Yes, looks like it renders everything to a <canvas> element. Which is 
not so interesting from the layout POV - I had in mind a translation 
with more different HTML elements, I guess.

Practically speaking, it is a good choice. I recall some development 
blog post either for Atom or for VS Code where they described a decision 
to move from HTML elements to rendering the code file contents on a 
canvas as well. GitHub's online text editor uses <textarea> now (so it's 
probably the same in VS Code), although how the syntax highlighting gets 
applied anyway I don't quite understand.

Anyway, the previous approach was functional as well, if slower with 
larger files. But Atom or VS Code don't support free-form layout or 
embedding images in the buffer text, I think. The "newmacs" could as 
well have both kinds of buffers (one for large files/performance, 
another for advanced layout features).

Even if <canvas> is used for buffers, it doesn't have to be used for 
"chrome" (menus, buttons, window delimiters, fringes, mode lines). Using 
HTML (for example) just for that could bring the ability to render stuff 
on top of it all, such as alerts, popups, etc.

Microsoft also has a project that could be tried as a base (MIT 
Licensed): https://github.com/microsoft/vscode-webview-ui-toolkit. Or 
one could just use its internals for inspiration, because "Visual Studio 
Code design language" is probably not one of our goals.