> Emacs' default handling of windows (in emacs terminology it's "windows", not "buffers" that you're talking about) is painful, but you can improve that through various packages, like popper[1]
Whether I'm complaining about buffer handling or window handling is a matter of perspective. If some event causes Emacs to create a new buffer and to split my frame with a new window to display it, I see that as Emacs handling the buffer *by* creating a window. Not that it matters, because we all know what I mean, because we all share the pain.
It's such a universal issue that there are tons of packages and tips for trying to improve the situation, such as popper. I've tried several over the years and have given up on using any of them because it's always a game of whack-a-mole. There's always some new surprise that is not caught by the helper package and/or your own configuration. So, today, I just have some easy-to-hit key bindings to quickly close the most recent buffer/window, or change focus, etc. It's still a pain in the ass to sift through my buffer lists, but oh well.
> Depending on what problems you run in to and your skill level, it could be tricky to debug elisp programs. However, compare that to when you run in to some bug in VSCode... how are you going to debug that? You'll probably have to submit a bug report and wait for the developers to get to it (if they ever do)... how is that better than emacs?
I don't know anything about VSCode, honestly, but I'll pessimistically assume that its plugins are "closed" to the end-user. Is that true?
But, it's all a double-edged sword. Everyone acts like Emacs is so open that you or I can just go in and fix whatever we want, but that's obviously not true- neither in a strict technical sense (can't edit the tons of inner C code directly in my configs), nor in a practical sense. If Emacs is such that you or I can just hack some ELisp to improve whatever we want, then why haven't you or I fixed our troubles with TRAMP, or slow UI rendering, or the buffers/windows problems?
Is Emacs very hackable? Yes. Much more so than any other editing environment. Is it completely changeable? No. Not even close.
Yet, the trade-off is that there's no structure to anything. Packages all do their own thing, and tap into various parts of Emacs when they're loaded. So, if you load the same two packages in different orders, you can end up with different results. This is especially frustrating with keymaps. Plus, a lot of (most?) packages have auto-loading, which means you don't always even *know* the order in which your packages will load, so sometimes your Emacs will behave differently than other times even with no config changes!
I love the philosophy of making everything hackable, but there's definitely something to be said for enforcing some structure or limits on when and how things are modified.
By far the best part about other programming editors compared to Emacs is that I can install umpteen addons/plugins/whatever and still go to ONE settings menu and see/edit all of my keybindings. And those keybindings will always be correct, no matter how many times I restart the editor, no matter what order I do work during an editing session, etc.
> Despite the downsides of emacs, I still use and love it.
Same here. I love it, but I also hate it. It's so powerful and there's so much potential, but it's also just so bad in a lot of ways.
Closing thought:
Sometimes people say Emacs has bad defaults. But that makes it sound like it's just a matter of some settings. Like you just need to pick a nicer font, pick a nice color scheme, change some key bindings, and turn off the splash screen and that'll do it.
But, if you look at all of the buffer/window helper packages (e.g., popper), and all of the package-management helpers that basically every single one of us use (use-package, straight, elpaca, etc), and how many people ask for help with key binding (and use things like general.el), then it starts to seem like the issue of "bad defaults" isn't really about minor settings tweaks--it's just that Emacs doesn't really *work* that well by default.
I'm going to keep using it, but I'm not going to pretend that it's actually a good editor. It's not even actually a good application platform because a hung SSH connection through TRAMP or a slow-to-load email refresh in gnus or mu4e can take the whole thing down--imagine if your OS went down when an SSH connection dropped...
Whether I'm complaining about buffer handling or window handling is a matter of perspective. If some event causes Emacs to create a new buffer and to split my frame with a new window to display it, I see that as Emacs handling the buffer *by* creating a window. Not that it matters, because we all know what I mean, because we all share the pain.
It's such a universal issue that there are tons of packages and tips for trying to improve the situation, such as popper. I've tried several over the years and have given up on using any of them because it's always a game of whack-a-mole. There's always some new surprise that is not caught by the helper package and/or your own configuration. So, today, I just have some easy-to-hit key bindings to quickly close the most recent buffer/window, or change focus, etc. It's still a pain in the ass to sift through my buffer lists, but oh well.
> Depending on what problems you run in to and your skill level, it could be tricky to debug elisp programs. However, compare that to when you run in to some bug in VSCode... how are you going to debug that? You'll probably have to submit a bug report and wait for the developers to get to it (if they ever do)... how is that better than emacs?
I don't know anything about VSCode, honestly, but I'll pessimistically assume that its plugins are "closed" to the end-user. Is that true?
But, it's all a double-edged sword. Everyone acts like Emacs is so open that you or I can just go in and fix whatever we want, but that's obviously not true- neither in a strict technical sense (can't edit the tons of inner C code directly in my configs), nor in a practical sense. If Emacs is such that you or I can just hack some ELisp to improve whatever we want, then why haven't you or I fixed our troubles with TRAMP, or slow UI rendering, or the buffers/windows problems?
Is Emacs very hackable? Yes. Much more so than any other editing environment. Is it completely changeable? No. Not even close.
Yet, the trade-off is that there's no structure to anything. Packages all do their own thing, and tap into various parts of Emacs when they're loaded. So, if you load the same two packages in different orders, you can end up with different results. This is especially frustrating with keymaps. Plus, a lot of (most?) packages have auto-loading, which means you don't always even *know* the order in which your packages will load, so sometimes your Emacs will behave differently than other times even with no config changes!
I love the philosophy of making everything hackable, but there's definitely something to be said for enforcing some structure or limits on when and how things are modified.
By far the best part about other programming editors compared to Emacs is that I can install umpteen addons/plugins/whatever and still go to ONE settings menu and see/edit all of my keybindings. And those keybindings will always be correct, no matter how many times I restart the editor, no matter what order I do work during an editing session, etc.
> Despite the downsides of emacs, I still use and love it.
Same here. I love it, but I also hate it. It's so powerful and there's so much potential, but it's also just so bad in a lot of ways.
Closing thought:
Sometimes people say Emacs has bad defaults. But that makes it sound like it's just a matter of some settings. Like you just need to pick a nicer font, pick a nice color scheme, change some key bindings, and turn off the splash screen and that'll do it.
But, if you look at all of the buffer/window helper packages (e.g., popper), and all of the package-management helpers that basically every single one of us use (use-package, straight, elpaca, etc), and how many people ask for help with key binding (and use things like general.el), then it starts to seem like the issue of "bad defaults" isn't really about minor settings tweaks--it's just that Emacs doesn't really *work* that well by default.
I'm going to keep using it, but I'm not going to pretend that it's actually a good editor. It's not even actually a good application platform because a hung SSH connection through TRAMP or a slow-to-load email refresh in gnus or mu4e can take the whole thing down--imagine if your OS went down when an SSH connection dropped...