Comment by Zambyte
11 hours ago
Ooo this is nice. I may have to try to get this working with my personal setup using Emacs and Sway.
My long term vision is to make an Emacs implementation that is compatible only in philosophy. It would use Guile instead of Elisp, default to bindings that are more familiar to people coming from more modern systems, and would be built from the beginning with concurrency and graphics in mind. For now it remains a dream though.
I know, right? However, one of the strongest points of Emacs is the huge amount of existing packages.
https://guile-emacs.org/
I'm familiar. The difference is that this is targeting source compatibility with existing Elisp. I don't feel like that is worth it for most people who would be interested in what I want to build.
VSCode is pretty much this. But with typescript instead of Guile. After 30 years of Emacs, I switched .
Heresy! ;)
I would guess you hadn't done as much emacs yak shaving as some of us other emacs users if the switch to VSCode was a simple one
after 30 years you say this? this cannot be serious.
Sounds like you want Lem. Though it's common lisp instead of guile.
https://github.com/lem-project/lem
Nope! I should have elaborated, but by "graphics in mind" I meant full support for graphical applications. I want it to be a Wayland compositor. It would either be used as a top level compositor like EXWM, or as a nested compositor, like how gamescope is used.
I want it to be as easy to make scripts to automate graphical applications as it is to automate textual ones in Emacs or shell scripts.
Yeah fair enough. I think we likely agree, too.
As I said in my other comment in this topic I actually would love to see an arch where the UI portions are split up with a background daemon holding buffers, lisp execution etc and then IPC to frontend pieces for window management and buffer editing.
So window management can be done by ... a window manager, but with intelligent interaction to the editor pieces so you don't lose all the awesome emacs stuff.
EDIT: I would say however that something like lem is probably more amenable to that refactoring/restructuring than GNU emacs, which is a single-threaded monolith.