10 ms·

So, I kind of like the idea of Emacs Lisp providing a GUI toolkit, and then the Emacs interface being implemented, in Emacs Lisp, with that toolkit. It's the mo

So, I kind of like the idea of Emacs Lisp providing a GUI toolkit, and then the Emacs interface being implemented, in Emacs Lisp, with that toolkit. It's the most Emacs way of doing things. However! There is one big thing you lose. I enjoy using a TUI for certain things, either on low-resource devices, or an actual vintage terminal, and so on. And it is currently the case that programs written for Emacs almost always degrade smoothly from the graphical display to the terminal, which makes Emacs apps like ement.el, nov.el, or mastodon.el the absolute best TUIs available for their respective tasks. That's something I'd dearly hate to lose. You could sort of work around that by defining abstract widgets and providing both GUI and TUI implementations, but that constrains the GUIs a lot, and gives you something possibly not much better than what we have now.

cmrdporcupine 3y ago
feels like the right thing here is for the library present a declarative API ("i need these pieces of info of this kind") and then have separate GUI and TUI backends, with the ability to override the rendering options for either but, yeah, that kind of thing always sounds great in theory, but is always ridiculously hard to get right in practice
iscream26 3y ago
> So, I kind of like the idea of Emacs Lisp providing a GUI toolkit, and then the Emacs interface being implemented, in Emacs Lisp, with that toolkit. I was just thinking this myself. I was thinking about a small, limited-vocabulary (widgets) GUI toolkit (implemented without web technologies) inside of Emacs that could still be navigated with a keyboard. GUI windows would be differentiated from buffer windows, and so functions that are defined for one of them couldn't be enabled on the other. Packages could implement their functionality in either type of window, or both, depending on their purpose. > I enjoy using a TUI for certain things, either on low-resource devices, or an actual vintage terminal, and so on. [...] That's something I'd dearly hate to lose. In the imaginary implementation I described above those would still work, they would be buffer-interface-only packages. They wouldn't have to be re-implemented nor updated to keep working properly. > You could sort of work around that by defining abstract widgets and providing both GUI and TUI implementations, but that constrains the GUIs a lot [...] It doesn't have to be that way. If GUIs and buffers are defined as different types of interface paradigms that can be used and modified within Emacs, then GUIs could be completely different from their buffer counterparts and vice versa. Packages that wouldn't make sense having on a terminal wouldn't have to implement a buffer interface for it. And not every package would have to implement its own GUI interface either if there's no need for it; buffers are a very simple data model with a vast amount of tooling for them that can all (in theory) work in tandem, so they would still be an attractive baseline for any developer looking to extend the functionality of their editor.
ttepasse 3y ago
In a way Lisp and S-Expressions would are tailor-made to define an abstract UI structure like JSX, SwiftUI and such, which then gets rendered into concrete UI widgets or a TUI. Something like defining a common editor layout this: (def-frame (vertical-split ( (horizontal-split ( (scrollview (tree-list)) (scrollview (editor-buffer))) (mode-line) (minibuffer)))) Plus the actual data with a reactive flow, of course. And, yes, not a Lisp programmer. I hope I put enough parentheses there.

cmrdporcupine 3y ago

feels like the right thing here is for the library present a declarative API ("i need these pieces of info of this kind") and then have separate GUI and TUI backends, with the ability to override the rendering options for either but, yeah, that kind of thing always sounds great in theory, but is always ridiculously hard to get right in practice

iscream26 3y ago

> So, I kind of like the idea of Emacs Lisp providing a GUI toolkit, and then the Emacs interface being implemented, in Emacs Lisp, with that toolkit. I was just thinking this myself. I was thinking about a small, limited-vocabulary (widgets) GUI toolkit (implemented without web technologies) inside of Emacs that could still be navigated with a keyboard. GUI windows would be differentiated from buffer windows, and so functions that are defined for one of them couldn't be enabled on the other. Packages could implement their functionality in either type of window, or both, depending on their purpose. > I enjoy using a TUI for certain things, either on low-resource devices, or an actual vintage terminal, and so on. [...] That's something I'd dearly hate to lose. In the imaginary implementation I described above those would still work, they would be buffer-interface-only packages. They wouldn't have to be re-implemented nor updated to keep working properly. > You could sort of work around that by defining abstract widgets and providing both GUI and TUI implementations, but that constrains the GUIs a lot [...] It doesn't have to be that way. If GUIs and buffers are defined as different types of interface paradigms that can be used and modified within Emacs, then GUIs could be completely different from their buffer counterparts and vice versa. Packages that wouldn't make sense having on a terminal wouldn't have to implement a buffer interface for it. And not every package would have to implement its own GUI interface either if there's no need for it; buffers are a very simple data model with a vast amount of tooling for them that can all (in theory) work in tandem, so they would still be an attractive baseline for any developer looking to extend the functionality of their editor.

ttepasse 3y ago

In a way Lisp and S-Expressions would are tailor-made to define an abstract UI structure like JSX, SwiftUI and such, which then gets rendered into concrete UI widgets or a TUI. Something like defining a common editor layout this: (def-frame (vertical-split ( (horizontal-split ( (scrollview (tree-list)) (scrollview (editor-buffer))) (mode-line) (minibuffer)))) Plus the actual data with a reactive flow, of course. And, yes, not a Lisp programmer. I hope I put enough parentheses there.