Specifically I want to spend time stepping through the main loop, to see if there can be fixes to the perceived slowness of certain operations. Unfortunately, the issue is coupled to how most Elisp is written. The solution to that is likely a much more massive undertaking.
I want Emacs to serve the same purpose that electron serves. It is a programming platform.
Perhaps we should place Elisp as the language for editing, in the sense that it provides editing primitives such as buffers, point and mark etc. alongside LISP level meta-programming. At least, it is supposed to be the language, but some of the design decisions behind Elisp were not optimal.
The Emacs Widget project could provide an opportunity to improve the design of Elisp not just around the editor-specific ingredients but as a whole, as a programming language, given that one of the aims is Emacs as a programming platform, and also given the situation that Elisp is the language behind the platform.
- Perhaps, first of all things, an FFI for C, this is so that Elisp can better interact with the rest of the world;
- Use lexical scoping;
- I have heard somewhere that Emacs uses gap buffers internally, is it possible or within the scope of the Emacs Widget to experiment with alternatives?
- In my current understanding, (one of) the primitive(s) of graphics(, and possibly the most important,) is the idea of a shape, is it possible to design a structure (or better, use lists) to encode this idea? Or is this already how things are done in SDL or general computer graphics? If we can expose such a primitive to Elisp, graphics manipulation could become as easy to manipulate as buffers and the text within;
- This is probably minor, but currently in Emacs, using terminal emulators very often lead to prompts saying “not a fully functional terminal”. Maybe we can embed a fully functional terminal into Emacs once the Emacs Widget reaches maturity, and enable better integration with pure UNIX workflow.
These are just thoughts which have immediately emerged after glancing through the post, I apologize for reading in such haste and making such vague, transient comments, which could be poorly thought out. I will likely reread the Manifesto and related posts with greater care, and reorganize my thoughts and share them here if new substances occur to me.
Perhaps we should place Elisp as the language for editing, in the sense that it provides editing primitives such as buffers, point and mark etc. alongside LISP level meta-programming. At least, it is supposed to be the language, but some of the design decisions behind Elisp were not optimal.
The design decisions can be compensated with good practices. I don’t mind taking some of these ideas into a systems-programming subset of Elisp that maps 1/1 to C. The main issue as I see it, is that we want to retain backwards compatibility as much as possible. And that means the changes need to be surgical.
The Emacs Widget project could provide an opportunity to improve the design of Elisp not just around the editor-specific ingredients but as a whole, as a programming language, given that one of the aims is Emacs as a programming platform, and also given the situation that Elisp is the language behind the platform.
Elisp has a lot of low-handing fruit to get fixed. The GC, though I don’t particularly like the implementation, is a step in the right direction, and it can be saved.
Another opportunity is to use Elisp for UI definition. Qt has QML, the web has HTML and GTK has a new language as well. Elisp can be the equivalent for the Emacs platform, and in some ways vastly superior. We know that transients are fairly easy to write and quite powerful.
The third thing is to use this as an opportunity to create vast amounts of Elisp that is a direct upgrade to the elisps that were written years ago. Create an impetus for people to write new packages, new code and fix up the old stuff.
The packages in core seem to universally lag behind the external packages and I don’t find this particularly encouraging. However, for some things, such as the widget toolkit, this is a blessing. So we get the opportunity to encourage more code being written. Emacs being the first programming platform for many people.
Perhaps, first of all things, an FFI for C, this is so that Elisp can better interact with the rest of the world;
Not easy, but I was thinking about that. In some ways this is inevitable, because one would like to be able to call into .so libraries directly from Elisp.
Use lexical scoping;
Emacs already nags you to hell and back. I can see this becoming a default soon.
I have heard somewhere that Emacs uses gap buffers internally, is it possible or within the scope of the Emacs Widget to experiment with alternatives?
Necessary. One of the things I want to try is replacing gaps with ropes and move into a message-passing process-based concurrency model.
Before that happens some abstractions need to be built in. Widgets can serve as that abstraction.
In my current understanding, (one of) the primitive(s) of graphics(, and possibly the most important,) is the idea of a shape, is it possible to design a structure (or better, use lists) to encode this idea? Or is this already how things are done in SDL or general computer graphics? If we can expose such a primitive to Elisp, graphics manipulation could become as easy to manipulate as buffers and the text within;
Touchy subject. But you can’t let SDL lead the way.
This needs to be more of a lisp that has some glue that uses SDL; (with some direct bindings to by-pass for performance critical work). But this needs to feel like lisp. That means that shapes are lists. There’s also some opportunities to extend the Elisp data model, but I think that this would make the number of caveats and exceptions even greater, leading to poor design experience.
The right thing to do is to make Elisp be capable of everything that you want to do from SDL. Fast. Reliable. The goal is, as you said,
(to) expose such a primitive to Elisp, graphics manipulation could become as easy to manipulate as buffers and the text within;
This is probably minor, but currently in Emacs, using terminal emulators very often lead to prompts saying “not a fully functional terminal”. Maybe we can embed a fully functional terminal into Emacs once the Emacs Widget reaches maturity, and enable better integration with pure UNIX workflow.
That is by design.
I don’t know if we can fix this, but I frankly wouldn’t bother. If something uses ncurses as a UI, you need a separate way of handling that to a terminal printing line-by-line feedback.
The eshell shouldn’t aspire to be a fully-fledged terminal emulator. It should be easy to wrap any terminal application into an Emacs package, so that ideally you’re always dealing with something as powerful as a terminal, but which leverages the modern technology stack, rather than cosplaying as a teletype.
These are just thoughts which have immediately emerged after glancing through the post, I apologize for reading in such haste and making such vague, transient comments, which could be poorly thought out.
No need to apologise, you’ve read it far more thoroughly than most.
Incidentally
Do you mind if I add these as FAQ items. I would like these ideas to be known to everyone that is reading this.
Excuse me for the late reply, some trivial issue had to be dealt with and occupied my attention earlier.
For now, let me organize current thoughts into three categories: interoperability enhancement, TUI improvements, and GUI reinvention.
Interoperability Enhancement
Not easy, but I was thinking about that. In some ways this is inevitable, because one would like to be able to call into
.solibraries directly from Elisp.
I haven’t had any experience in completing a functional program or piece of software (my experience in programming is currently very limited, mostly small chunks of code or scripts to configure the environments for personal studies), let alone designing such things as FFI. For now I can only imagine just how difficult or cumbersome it can be to implement, just how large the scale of engineering it takes. The FFI itself could be a long-term goal; however, after reorganization, I believe what’s truly important is the motivation behind an FFI, namely better interoperability with system-level languages and utilities.
This may be due to my limited experience in Emacs, that I haven’t yet dived into the related use cases before, but I do get the impression that, though you can do everything in Emacs (and only after huge amount of configuration), it is very rare and somewhat forbidding to embed Emacs and Elisp in a workflow larger than Emacs itself. Emacs tries to wrap around the system, but it seldom tolerates being a component in something larger or more final. But for most users, I imagine, Emacs is ultimately an instrument to serve the work, a fantastic and breathtaking one for sure, but still; as such, it needs to allow itself to cooperate more smoothly with other tools.
This could also prevent the future possibility, as remote as it might seem for now, where it becomes an isolated leviathan stranded on its own island.
Enhancing interoperability may also have been what I was unconsciously thinking when suggesting the consideration of a faithful embedding of terminal emulators (instead of merely for the sake of “containing” the functionalities of terminals). But now that I believe interoperability is the true goal here, it may not take the specific form of a C FFI or an embedding of terminals. But I believe some form(s) of better interoperability should be on the roadmap; the specific approaches taken to achieve this may require much deeper discussions.
TUI Improvement
GUI objects can render text; they are a superset of textual interfaces.
I agree with this specifically, but feel the need to say that: though the drawing of text may be a special case of drawing on the screen, when it comes to handling them, I think we do need to differentiate between text and graphics, because text, buffers, windows etc. come in discrete units, they have analogues in pen-and-paper, and there are agreed-upon conventions to writing and reading in natural languages; whereas graphics can be more continuous, more mutable, at least conceptually. (Hence the separation of TUI Improvements and GUI Reinvention.)
One of the things I want to try is replacing gaps with ropes and move into a message-passing process-based concurrency model.
I would also suggest considering a data structure which makes the idea (or the action) of an “edit” transparent. So the buffer could be represented as an accumulation or a history of edits, and there would be no need to worry about where the edit takes place and whether it affects only the local region of the text or the global. Perhaps something akin to a piece table? Maybe even a custom data structure! Another benefit of this edit-oriented approach becomes apparent if we take into account the possibility where there are (possibly more than one) incremental subroutines occurring alongside the main event loop, for understanding user edits and updating the graphics or another associated buffer or window.
GUI Reinvention
Another opportunity is to use Elisp for UI definition. Qt has QML, the web has HTML and GTK has a new language as well. Elisp can be the equivalent for the Emacs platform, and in some ways vastly superior.
This needs to be more of a lisp that has some glue that uses SDL; (with some direct bindings to by-pass for performance critical work). But this needs to feel like lisp. That means that shapes are lists.
I agree completely; and maybe this has been what you have in mind all along, but just to emphasize, I believe that instead of devising a separate UI definition language to conjure up a heterogeneous pairing like HTML + Javascript, we should use Elisp code itself for UI definition, for imo the power of LISP is very much rooted in the uniform usage of lists.
Maybe shapes could be specified as nested lists, the leaves of which being points, with a pair of points being a line segment, and a bunch of line segments whose endpoints cancel out form a 2-dimensional shape / boundary / cycle, and so on (so this is essentially a chain complex). In this way we could, in principle, build shapes or globs of any dimension. Perhaps the transition between points and positions on the screen needs to happen at the periphery of Elisp and SDL.
Do you mind if I add these as FAQ items.
Of course not, it would be a pleasure of mine. 
There could be various things and terminologies in your posts and comments whose meaning or denotation I do not fully grasp, and many choices you are considering whose implications I do not fully appreciate. I will try to look them up in my spare time, because this is really interesting and I wish to be able to understand the future progress of the Emacs Widget project.
I finally managed to read the FAQ and the posts here.
Sadly I can’t provide much technical commentary as my C and elisp knowledge is extremely limited but I will try to add some conceptual comments.
I really like that this would strengthen the idiom that Emacs is a graphical text based shell (my use case 
).
Here a little conversation I just had with ChatGPT about the topic: ChatGPT - Text-based Graphical Shell
The summary
What Emacs Actually Is:
- A text-based graphical shell in terminal mode
- A graphical text-based shell in GUI mode
- A self-hosted, programmable platform (via Emacs Lisp)
- A toolkit for building interfaces within a textual UI
- Not a kernel or OS—but a rich application layer
If I understand you correctly, you want to build a:
- A toolkit for building graphical interfaces within a textual UI
I’m also reminded of Blender’s usage of OpenGL to render their UI.
Am I on the right track or completely in the weeds?