[Top][All Lists]

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

Re: Emacs design and architecture

From: Dmitry Gutov
Subject: Re: Emacs design and architecture
Date: Sat, 16 Sep 2023 01:20:59 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0

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>,
Date: Fri, 15 Sep 2023 20:36:07 +0200

Maybe it would be worth looking at emacs-ng


The README lists the feature


   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.

reply via email to

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