(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