(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.
3 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
How exciting, looking forward to it![1]
I am an amateur and probably won’t be able to fully digest the discussion, let alone providing useful feedback, but will definitely be there! ↩︎
1 Like
So roughly the plan around that is not to fix concurrency in Elisp. It’s just not a practically solvable problem.
Instead we rely on the fact that you don’t necessarily need to have the same lisp machine in all the components. Just some lisp machine that is aware of the global state.
So you can break up the execution into islands that can freely communicate via some form of IPC, probably something specific to Emacs with a symbolic expression bent. You now don’t block when your LSP hangs, because the process that controls the main window isn’t the one that blocks on the LSP.
This means that some core components would need to be rewritten to facilitate message-passing, and this is not something that I would do with the initial implementation. But it would allow you to have a concurrent, not necessarily parallel implementation of Emacs.
2 Likes
@appetrosyan , you should check this out: https://codeberg.org/ramin_hal9001/gypsum/issues/16
Hello,
When I click on the link in the original post I got a 404 HTTP code. Browsing your blog posts, I don’t see this post.
Any other place where I can read your post. I think I read it already, sometimes ago, but I am not sure anymore. As the topics interest me I would like to be sure of the content of the blog post before emitting any idea.
Thanks.
This is not the article I thought I read, but thanks for the link anyway, quite a lot of information to process.
And if I may, @appetrosyan here is the article I was referring to Emacs GUI library · Andrey Listopadov.
I wish I read this article before writing mine.
The number of people writing about this seems to indicate a great appetite for the feature.
1 Like
Also, regarding the 404. I migrated to hugo since that article was originally published, so the URL is slightly different now.
1 Like
Maybe it is time to get in touch with Mr. Listopadov, and get him onboard. So he can share its thought and hopefully makes this discussion goes forward to an actual project.
And to add to the ambient noise, here are a few thoughts and ideas I have written over the year and I am still updating on what I would like to see in emacs, especially for a version that include a widget toolkit.
They are really a big pile of ideas and thoughts, which lacks structures. So be indulgent 