[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.
- Re: Emacs design and architecture, (continued)
- Re: Emacs design and architecture, Gerd Möllmann, 2023/09/16
- Re: Emacs design and architecture, Dmitry Gutov, 2023/09/16
- Re: Emacs design and architecture, Sebastian Miele, 2023/09/16
- Re: Emacs design and architecture, Po Lu, 2023/09/16
- Re: Emacs design and architecture, Gerd Möllmann, 2023/09/16
- Re: Emacs design and architecture, Po Lu, 2023/09/16
- Re: Emacs design and architecture,
Björn Bidar <=
- Re: Emacs design and architecture, Dmitry Gutov, 2023/09/16
- Re: Emacs design and architecture, Gerd Möllmann, 2023/09/16
- Re: Emacs design and architecture, Dmitry Gutov, 2023/09/16
- Re: Emacs design and architecture, Gerd Möllmann, 2023/09/16
- Re: Emacs design and architecture, Lynn Winebarger, 2023/09/16
- Re: Emacs design and architecture, Gerd Möllmann, 2023/09/16
- Re: Emacs design and architecture, Dmitry Gutov, 2023/09/16
- Re: Emacs design and architecture, Gerd Möllmann, 2023/09/16
- Re: Emacs design and architecture, Po Lu, 2023/09/16
- Re: Emacs design and architecture, Dmitry Gutov, 2023/09/16