@ArneBab Also, we need a guile wayland compositor I guess :)
6 comments
@ArneBab that's a little sad, but it's hard to innovate without breaking some backward compatibility, however it seems wayland does a relatively good job on gradual migration with xwayland and other things. IMO emacs is already quite bloated and we should decompose it parts and reuse them on one level above it, rather than include more functionality inside. @ArneBab The problem is that only unified things are inside emacs, but all other programs either rarely emulate emacs behavior or (what is more usual) have ad-hoc not consistent solutions. Solutions for completion, candidate navigation, window/pane management, tabs and a few (or many) other things. IMO all those tools should be implemented on the level above the emacs and be composable so all the apps can benefit from it. @abcdw Do you know emacsy? (was it you who wrote it?) https://www.nongnu.org/emacsy/manual/emacsy.html#The-Garden @ArneBab Yep, heard of it, cool stuff. Not exactly the way I have in mind to proceed on unification/emacsyfication, but definetly a good try. |
@abcdw likely we will, yes … though I’m not happy about the breakage wayland brings.
I’d hate losing exwm, but I don’t see whether there’s anyone who would be up for porting it to wayland.
I’m also not sure whether wayland is a good match for maintaining program-UIs in emacs windows.