|
Top-level
 @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. 4 comments
@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. |
Gregory's Server
@abcdw When I look at Emacs as a programming environment, I do not see it as bloated. I would not call Python bloated for having many libraries ("batteries included"), so why should Emacs be bloated.
Bloat would be if you had to *use* many of them to do anything, but that’s not the case.
It’s a shared programming environment.
And I like working in exwm very much: this actually unifies and streamlines many of my workflows (which start and end in org-mode).
1/2
@abcdw When I look at Emacs as a programming environment, I do not see it as bloated. I would not call Python bloated for having many libraries ("batteries included"), so why should Emacs be bloated.
Bloat would be if you had to *use* many of them to do anything, but that’s not the case.
It’s a shared programming environment.