4 ms·

> to this day I still don't see what the hype was about. As an Emacs user[1], I agree. The flexibility is really cool, and there are a handful of Emacs applica

> to this day I still don't see what the hype was about. As an Emacs user[1], I agree. The flexibility is really cool, and there are a handful of Emacs applications (notice I didn't call them "packages") that are "killer apps", like Magit, Org-Mode, Calc, etc. But, even though I do use and like Emacs, I can't honestly recommend it to anyone and I wouldn't even consider it to be a very good programming environment unless you're specifically working in a Lisp/Scheme (where it's awesome). These days, I mostly use Emacs for programming in Rust and for using Magit as a git porcelain even when not using Emacs for the actual code editing. Here are the things that suck[2] about Emacs (mostly from the point of view of a programming text editor): * The UI is slow. Don't tell me that it's "only" when we have long lines, or too much syntax highlighting or whatever. Sure, if I turn off all of the useful programming features, the UI updates fast enough for me to not notice any latency, but any time I open a file that uses a LSP server or equivalent (not just Rust- I've done Clojure, JavaScript, PHP, and C++ in Emacs), the latency for even just moving the cursor around is noticeable and it's distracting. * Tramp sucks. I don't understand how everyone says that Tramp is awesome and magical. Every single time I've tried to use it to do anything, it's been a bad experience. It's been a few years since I've even tried it, but I remember having to wrestle with ssh-agent authentication, some packages not playing nicely with it (besides the "obvious" ones like LSP-mode), and the whole application hanging if the Tramp session hung for some reason. * It's actually really HARD to customize properly. The experts say that Emacs is "self-documenting" and "introspectable", but many times, I'll try to customize some behavior or a keymap or something, and I'll read the documentation for a variable or function and it'll say something like "takes a plist of FOO definitions,"--well, what the heck does a "FOO" definition look like? What are the keys for the plist? What are acceptable values for those keys? It's very common to just have to dig through the actual elisp code to find out. Then, you'll find out that your customization doesn't even work correctly because some other mode or function stomps on your code, or gets initialized in a different logic path that isn't affected by your change. Since every feature and every package is different, you have little chance of just figuring out a few conventions or any standard structure for packages. * Handling buffers is tedious. Sometimes buffers appear and take over the whole frame, sometimes they split the frame and steal focus, and sometimes they split the frame and don't steal focus. And it's very ad-hoc and tedious to try to separate out "background, system buffers" from "my actual work buffers". There are tons of Emacs packages that attempt to make it easier to manage buffers, switch between them more easily, group them in lists, etc. Like I said, I like Emacs. But, I also run Linux on my personal machines and run a de-Googled AOSP ROM on my rooted Android phone. UX, polish, and convenience are obviously not a high priority for me. [1]: I've used Emacs to varying degrees and with varying levels of dedication and hardcore-ness since 2008-ish. At a few points, I would've said that I was pretty competent/proficient in Elisp, and have authored some fairly elaborate functions to help me with common tasks within Emacs. I even use to try to do a version of "literate programming" with org-mode and org-mode babel blocks in place of something like Jupyter notebooks for Python. [2]: Yes, this is a very negative comment, but I tend to complain loudest about the things that I love and care about. I don't complain or criticize things that I don't like or don't want to use.

BeetleB 4y ago
> Handling buffers is tedious. I feel the pain. I often daydream about spending time customizing it to my needs, and add that to the other 576 ways I want to customize it and don't have time. And then I sigh and remind myself "At least it's better than tabs!" before I return to my tasks at hand.
ithrow 4y ago
I have love/hate relationship with Emacs too, but for the stuff I do in Emacs I hate other software more. So Emacs it is.
pmoriarty 4y ago
I love emacs, but agree with many of your criticisms. Emacs can be slow. I don't use LSP, so can't comment on that, but it's definitely slow on long lines with syntax highlighting. I don't use TRAMP for exactly one of the reasons you mentioned: it can hang Emacs. I want to avoid that at all costs, because I pretty much live in Emacs. 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] 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? Also, remember that you don't have to go it alone in troubleshooting the issues you run in to with emacs. There's a whole community ready and willing to help. Despite the downsides of emacs, I still use and love it. Every editor has downsides, and emacs is no exception. Its positives far, far outweigh the negatives for me. There's just so much more that it can do than other editors, and it's far more customizable. I very much doubt I'll ever seriously consider switching to another. [1] - https://github.com/karthink/popper https://github.com/karthink/popper
- ragnese 4y ago
  > 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...

BeetleB 4y ago

> Handling buffers is tedious. I feel the pain. I often daydream about spending time customizing it to my needs, and add that to the other 576 ways I want to customize it and don't have time. And then I sigh and remind myself "At least it's better than tabs!" before I return to my tasks at hand.

ithrow 4y ago

I have love/hate relationship with Emacs too, but for the stuff I do in Emacs I hate other software more. So Emacs it is.

pmoriarty 4y ago

I love emacs, but agree with many of your criticisms. Emacs can be slow. I don't use LSP, so can't comment on that, but it's definitely slow on long lines with syntax highlighting. I don't use TRAMP for exactly one of the reasons you mentioned: it can hang Emacs. I want to avoid that at all costs, because I pretty much live in Emacs. 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] 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? Also, remember that you don't have to go it alone in troubleshooting the issues you run in to with emacs. There's a whole community ready and willing to help. Despite the downsides of emacs, I still use and love it. Every editor has downsides, and emacs is no exception. Its positives far, far outweigh the negatives for me. There's just so much more that it can do than other editors, and it's far more customizable. I very much doubt I'll ever seriously consider switching to another. [1] - https://github.com/karthink/popper https://github.com/karthink/popper

ragnese 4y ago
> 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...