emacs-devel
[Top][All Lists]
Advanced

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

Re: Emacs design and architecture


From: Björn Bidar
Subject: Re: Emacs design and architecture
Date: Sat, 16 Sep 2023 17:20:16 +0300
User-agent: Gnus/5.13 (Gnus v5.13)

Po Lu <luangruo@yahoo.com> writes:

> Sebastian Miele <iota@whxvd.name> writes:
>
>> 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.
>>
>> 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.
>>
>> Disclaimer: I really do not know the details.  This is only a
>> superficial view gained during the last months.
>
> ISTM that it would be more productive to examine LibreOffice.  We do
> wish to turn Emacs into a word processor, after all.  And LibreOffice
> provides layout capabilities that are in no way inferior to those
> supplies by the editors found within web browsers, all while being
> designed to edit rather than display documents.

>From my point of view Emacs slowly turns into an environment that runs
modes that greatly become to behave more like applications rather than
extensions to a program. Emacs is in someway like a web browser or a
jvm.

These more extensive modes require more advanced features similar as
when turning Emacs into a "word processor".
In my opinion Emacs being single threaded is the biggest hurdle in that,
gui lockup is the biggest no no in regular gui apps.



reply via email to

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