The Emacs widget toolkit | Aleksandr Petrosyan

(Accidentally deleted the previous post)

1 Like

This is very interesting. The only tenet would be “document as graphics”, or more accurately “elisp code as graphics”, and the only requirement would be a (very very very) careful choice of the “atoms” of gui to be exposed to elisp (any additional requirement may impose unnecessary limitations). And instead of restricting to one format (which in this context could mean a document-to-graphics mapping), there could be any number of such formats, maybe with one or a few of them built-in, and the users can specify their own format as they see fit, as long as Emacs understands it in terms of the combinations of the “atoms” in the end. I hope that the proposal in this link will be heard by more of both users and developers, and will begin to take shape soon, and if it does, it could aim to be something far more versatile than frameworks like electron, not merely a substitute or a competitor.

1 Like

Author here.

I did not expect this post to blow up, this is a bit early, as the blog is still quite rough around the edges. More updates to come

I want to do a more detailed discussion of how the TUI and Text work, before diving head-first into the weeds of display code.

he only tenet would be “document as graphics”, or more accurately “elisp code as graphics”, and the only requirement would be a (very very very) careful choice of the “atoms” of gui to be exposed to elisp (any additional requirement may impose unnecessary limitations).

That is indeed the case.

I hope that the proposal in this link will be heard by more of both users and developers, and will begin to take shape soon, and if it does, it could aim to be something far more versatile than frameworks like electron, not merely a substitute or a competitor.

That is the hope.

1 Like

Still reading but I can say that I agree and as far as I got agree with the paradigm.

Update when I digested the whole piece.

1 Like

I plan to create a more technical discussion of Emacs’ rendering internals. This discussion is a bit vapid without concrete explanations. And I got into a lot of hot water… let’s just say… on places like Reddit, because I haven’t explained the idea clearly.

2 Likes

I finally had the time to finish the read and I still agree.
One thing lingering in my mind is the single threaded nature of Emacs.
Drawing shouldn’t delay or even block user input and the current nature of multi core CPU and GPU systems it would be a waste to not be able to spread the load.

1 Like