[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: Mon, 18 Sep 2023 21:48:49 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0

On 16/09/2023 14:59, Sebastian Miele wrote:
From: Dmitry Gutov <dmitry@gutov.dev>
Date: Sat, 2023-09-16 14:02 +0300

On 16/09/2023 11:41, Gerd Möllmann wrote:
Dmitry Gutov<dmitry@gutov.dev>  writes:

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.
Looks like Javascript/Typescript to me?

Yep. But any attempt to reuse an existing browser engine would likely
have to deal with JavaScript on some level, I think.

In the foreseeable future, probably not.  I do not know the details.
But there is WebAssembly.  In order to access the DOM and possibly other
browser API, at least a few months ago, it was still necessary to
somehow go through JS.  But it is very unlikely that that will not
change in a not too distant future.  There are many developements going
on in that area that (will) make implementing further languages on top
of WebAssembly easier and the languages and APIs interoperable with less
and less overhead, and more and more common management (including GC).
I have only a very superficial view.  But in the last months I gained
the impression, that WebAssembly and standards and stuff around it
probably will become a very versatile and interoperable VM
infrastracture, including "WebAssamble-native" APIs to almost anything.

Wasm or JS, with this approach it seems like we'd need to compile Lisp to JS/WA, or use FFI, or (probably) both.

None of this is a deal-breaker for an experimental port/GUI, but it definitely doesn't make it a weekend project.

What may be interesting in that direction, too, are experimental browser
engines like Servo.  In the last months I read somewhere (and by people
contributing to it) that Servo more or less explicitly has the aim to
allow to take/use only parts of it, and to have as clear and
approachable source code as possible.  A next generation Emacs probably
would not need or even want all that a web browser has to support.  It
could concentrate on a subset of web-stuff that already is known to work
very well and efficiently.

Looking at these, it doesn't sound like it's easy to replace the current JS engine (Firefox's SpiderMonkey) with something else. Although to make it run Lisp would be pretty cool.


The comments in the latter led me to this, though:

https://github.com/fschutt/azul (Rust desktop GUI framework based on WebRender with no JavaScript involved, looks like).

reply via email to

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