4 ms·

I gave up on Emacs and went back to Vim because of the slowness and the bugs I was encountering while using the Emacs GUI (granted a lot of them were from lsp-m

I gave up on Emacs and went back to Vim because of the slowness and the bugs I was encountering while using the Emacs GUI (granted a lot of them were from lsp-mode and other heavy packages). While digging for answers I was told not to use certain platforms, don't use the GUI, use the GUI, don't turn Emacs off etc. which felt like Stockholm syndrome to me. There's a lot of cargo culted config fragments like the ones you'll find in the article. Why does every user have to constantly reinvent the same config to work around all of the issues in Emacs? I don't know, but I wasn't going to stick around and find out. Vim with all of my plugins, which has the same features as my Emacs config, starts up instantly and I've yet to encounter a single bug. I really wanted to like Emacs, and I've chalked up my bad experience to less people putting dev time towards it rather than actual negligence towards the user experience. In the article the author talks about how he's gone bankrupt three times with his config, maybe that's a sign that the problem isn't the author. If Emacs is that fragile, then its extensibility is really a moot point.

dilap 4y ago
Yeah, as soon as you start customizing emacs (which is the whole point of emacs), you run into bugs. Everything is always slightly broken all the time; I don't think it's actually humanly possible to fix this -- too many parts. Fix one thing, another thing breaks. I'm addicted to the flexibility, but I dream of something that offers the same level of flexibility in a more robust ecosystem (e.g. statically typed, statically scoped, what else?). (Is such a thing even possible? I don't know!)
- cheesewhizemacs 4y ago
  >Everything is always slightly broken all the time; I don't think it's actually humanly possible to fix this -- too many parts. Fix one thing, another thing breaks. Speak for yourself. Just last weekend I had a few hours with little to do, and actually wanted to do some yak shaving on my Emacs config just for the hell of it. but it works too well and I have everything the way I like it! My yak is f*kin' bald, man! Not only have I already worked out all the little bugs that annoy me, but I've added all the features I can think of that I want!
  - dilap 4y ago
    Well, I'm jealous! Here's my list of problems to solve on a rainy day†: ;; * kill-word-sp cancels ioccur mode for some reason ;; * after running ipython for a while, all terminal commands hang waiting for output ;; * iedit substition starts just corrupting shit (e.g., try replacing \t with spaces) ;; * "replace-match-maybe-edit: Match data clobbered by buffer modification hooks" ;; * delete-horizontal-space doesn't work w/ iedit mode ;; * vc-annotate doesn't properly restore window configuration ;; * the popup used by dumb-jump breaks when line wrapping is enabled and it's used on a wrapped line ;; * sometimes trying to launch a new shell just kills the old shell ;; * godef doesn't work when narrowed ;; * emacs stopped automatically recompiling .emacs wtf ;; * grep-ed while buffer is in loccur mode fucks things up ;; * undo in loccur mode messes things up ;; * visual-line-mode jumps around on very long lines (like paragraph long) ;; * parens don't overwrite properly in go-mode ;; * «Error running timer `auto-revert-buffers': (wrong-type-argument number-or-marker-p nil)» ;; * shell doesn't save history a lot of the time ;; * piece of shit grep edit silently fails on spaces on file names ;; * code-wrap is stupid with long separator lines (like "//---" for a long time) ;; - sadly might be a visual line mode bug, actually... ;; * line highlight doesn't work after jumping to a definition ;; * highlight line mode doesn't work on most recent line in shell ;; * tendency to identify buffers by name causes bugs when renaming buffers ("stringly typed") ;; * subword mode doesn't think DEBUG_MEGA_GOLD is three words (in a .go file) ;; * if a shell command tries to open a file in emacs, and the active window is the minibuffer, the file will open into the minibuffer Probably the biggest source of issues is two different modes not playing well with each other, which is understandable, but also something it feels like a less freeform approach to an editor might reasonably be able to do a better job of avoiding. † To be fair, not all bugs -- some are just configuration issues I haven't figured out yet.
    - ParetoOptimal 4y ago
      > ;; * emacs stopped automatically recompiling .emacs wtf Change to follow XDG specification and ~/.config/emacs having precedence?
      - 4y ago
- ParetoOptimal 4y ago
  > Yeah, as soon as you start customizing emacs (which is the whole point of emacs), you run into bugs. Everything is always slightly broken all the time; I don't think it's actually humanly possible to fix this -- too many parts. Fix one thing, another thing breaks. There's no difference between an advanced emacs config and a software project. If you don't test or incubate features long enough before your workflow depends on them you'll find yourself building atop more bugs. I find tagging releases of my emacs config useful for this.
  - dilap 4y ago
    For sure. But I think what's going wrong is a little different. E.g., there's a mode that highlights the current line. And there's a mode that let's you run a shell inside a buffer. And for some reason, the current line highlight doesn't work on the most-recent (waiting for input) line. OK, actually looking at this a little more closely, I think it's because shell mode does some sort of thing where it redefines the "start" of the line to not include the shell prompt, and I guess whatever is doing the line highlighting is using that same notion of "start" of line. So on a line that just contains the prompt, the line highlighter thinks the line is zero length, and highlights nothing. I think this is typical of lots of emacs problems. You have all these modes that interact w/ each other, w/o strong models of the interactions, so you end up with a bunch of little bugs. (And because there's combinatorially many different ways you can combine modes, I don't think testing is ever really going to help you here. You just need formal structures and coding styles that guarantee or lend themselves more to correctness.)
noctuid 4y ago
My init files are nearly 10k lines and I have >300 packages. I've never "declared .emacs bankruptcy." Emacs starts in 0.4-0.6 seconds (without the daemon) for me. One reason I initially switched to Emacs was because Vim was comparably slow as hell for what I was doing. That's no longer the case. Neovim and Vim are definitely faster than Emacs, but I almost never run into cases where it matters. Even on my crappy work laptop, the only time I ran into issues with Emacs is when dealing with log files that were gigabytes (in cases like that evil's :g and :s are just unusably slow). > There's a lot of cargo culted config fragments like the ones you'll find in the article. Besides changing the gc-cons-threshold (which is indeed a questionable fragment to blindly copy/paste), there were no other specific config fragments, only examples. People blindly paste config fragments for everything (e.g. set nocompatible in Vim). > Why does every user have to constantly reinvent the same config to work around all of the issues in Emacs? What is there to reinvent? It should take almost no extra configuration to properly defer package loading. Package loading is also not automatic. If you are explicitly loading every package you've installed during init, that's your fault. You shouldn't blindly copy things into your config. If you really don't want to handle configuration yourself, starter kits exist for a reason. > In the article the author talks about how he's gone bankrupt three times with his config, maybe that's a sign that the problem isn't the author. If Emacs is that fragile, then its extensibility is really a moot point. It is mostly a user problem. Emacs lets you do anything. It gives you enough rope to hang yourself with. I could write an unreadable and broken mess of a program in any programming language, but that doesn't say anything about whether a language is fundamentally flawed. It's a double-edged sword. There's no such thing as bug-free software. And the more functionality, the more room for misconfiguration and bugs. Vim/neovim come nowhere close in terms of functionality. The correct word isn't "fragile." A better word would be "malleable." It's the editable editor. Emacs' malleability is at least part of the reason why it's able to stay relevant despite the fact that it has very few developers compared to Vim and other editors. Because Emacs is this way, it's potentially easier to do something dumb or install a bunch of useless, slow packages, but because Emacs is this way we also have Magit, org-mode, and a bunch of other killer packages that Vim has much worse versions of (or no equivalent of at all). This means that if you only need a simple setup, Emacs is not that appealing, but my experience has been that I have no idea what I want until I know what is actually possible (e.g. I didn't grok magit until I read the entire manual and saw how greatly it would simplify my workflow).

dilap 4y ago

Yeah, as soon as you start customizing emacs (which is the whole point of emacs), you run into bugs. Everything is always slightly broken all the time; I don't think it's actually humanly possible to fix this -- too many parts. Fix one thing, another thing breaks. I'm addicted to the flexibility, but I dream of something that offers the same level of flexibility in a more robust ecosystem (e.g. statically typed, statically scoped, what else?). (Is such a thing even possible? I don't know!)

cheesewhizemacs 4y ago
>Everything is always slightly broken all the time; I don't think it's actually humanly possible to fix this -- too many parts. Fix one thing, another thing breaks. Speak for yourself. Just last weekend I had a few hours with little to do, and actually wanted to do some yak shaving on my Emacs config just for the hell of it. but it works too well and I have everything the way I like it! My yak is f*kin' bald, man! Not only have I already worked out all the little bugs that annoy me, but I've added all the features I can think of that I want!
- dilap 4y ago
  Well, I'm jealous! Here's my list of problems to solve on a rainy day†: ;; * kill-word-sp cancels ioccur mode for some reason ;; * after running ipython for a while, all terminal commands hang waiting for output ;; * iedit substition starts just corrupting shit (e.g., try replacing \t with spaces) ;; * "replace-match-maybe-edit: Match data clobbered by buffer modification hooks" ;; * delete-horizontal-space doesn't work w/ iedit mode ;; * vc-annotate doesn't properly restore window configuration ;; * the popup used by dumb-jump breaks when line wrapping is enabled and it's used on a wrapped line ;; * sometimes trying to launch a new shell just kills the old shell ;; * godef doesn't work when narrowed ;; * emacs stopped automatically recompiling .emacs wtf ;; * grep-ed while buffer is in loccur mode fucks things up ;; * undo in loccur mode messes things up ;; * visual-line-mode jumps around on very long lines (like paragraph long) ;; * parens don't overwrite properly in go-mode ;; * «Error running timer `auto-revert-buffers': (wrong-type-argument number-or-marker-p nil)» ;; * shell doesn't save history a lot of the time ;; * piece of shit grep edit silently fails on spaces on file names ;; * code-wrap is stupid with long separator lines (like "//---" for a long time) ;; - sadly might be a visual line mode bug, actually... ;; * line highlight doesn't work after jumping to a definition ;; * highlight line mode doesn't work on most recent line in shell ;; * tendency to identify buffers by name causes bugs when renaming buffers ("stringly typed") ;; * subword mode doesn't think DEBUG_MEGA_GOLD is three words (in a .go file) ;; * if a shell command tries to open a file in emacs, and the active window is the minibuffer, the file will open into the minibuffer Probably the biggest source of issues is two different modes not playing well with each other, which is understandable, but also something it feels like a less freeform approach to an editor might reasonably be able to do a better job of avoiding. † To be fair, not all bugs -- some are just configuration issues I haven't figured out yet.
  - ParetoOptimal 4y ago
    > ;; * emacs stopped automatically recompiling .emacs wtf Change to follow XDG specification and ~/.config/emacs having precedence?
    - 4y ago
ParetoOptimal 4y ago
> Yeah, as soon as you start customizing emacs (which is the whole point of emacs), you run into bugs. Everything is always slightly broken all the time; I don't think it's actually humanly possible to fix this -- too many parts. Fix one thing, another thing breaks. There's no difference between an advanced emacs config and a software project. If you don't test or incubate features long enough before your workflow depends on them you'll find yourself building atop more bugs. I find tagging releases of my emacs config useful for this.
- dilap 4y ago
  For sure. But I think what's going wrong is a little different. E.g., there's a mode that highlights the current line. And there's a mode that let's you run a shell inside a buffer. And for some reason, the current line highlight doesn't work on the most-recent (waiting for input) line. OK, actually looking at this a little more closely, I think it's because shell mode does some sort of thing where it redefines the "start" of the line to not include the shell prompt, and I guess whatever is doing the line highlighting is using that same notion of "start" of line. So on a line that just contains the prompt, the line highlighter thinks the line is zero length, and highlights nothing. I think this is typical of lots of emacs problems. You have all these modes that interact w/ each other, w/o strong models of the interactions, so you end up with a bunch of little bugs. (And because there's combinatorially many different ways you can combine modes, I don't think testing is ever really going to help you here. You just need formal structures and coding styles that guarantee or lend themselves more to correctness.)

noctuid 4y ago

My init files are nearly 10k lines and I have >300 packages. I've never "declared .emacs bankruptcy." Emacs starts in 0.4-0.6 seconds (without the daemon) for me. One reason I initially switched to Emacs was because Vim was comparably slow as hell for what I was doing. That's no longer the case. Neovim and Vim are definitely faster than Emacs, but I almost never run into cases where it matters. Even on my crappy work laptop, the only time I ran into issues with Emacs is when dealing with log files that were gigabytes (in cases like that evil's :g and :s are just unusably slow). > There's a lot of cargo culted config fragments like the ones you'll find in the article. Besides changing the gc-cons-threshold (which is indeed a questionable fragment to blindly copy/paste), there were no other specific config fragments, only examples. People blindly paste config fragments for everything (e.g. set nocompatible in Vim). > Why does every user have to constantly reinvent the same config to work around all of the issues in Emacs? What is there to reinvent? It should take almost no extra configuration to properly defer package loading. Package loading is also not automatic. If you are explicitly loading every package you've installed during init, that's your fault. You shouldn't blindly copy things into your config. If you really don't want to handle configuration yourself, starter kits exist for a reason. > In the article the author talks about how he's gone bankrupt three times with his config, maybe that's a sign that the problem isn't the author. If Emacs is that fragile, then its extensibility is really a moot point. It is mostly a user problem. Emacs lets you do anything. It gives you enough rope to hang yourself with. I could write an unreadable and broken mess of a program in any programming language, but that doesn't say anything about whether a language is fundamentally flawed. It's a double-edged sword. There's no such thing as bug-free software. And the more functionality, the more room for misconfiguration and bugs. Vim/neovim come nowhere close in terms of functionality. The correct word isn't "fragile." A better word would be "malleable." It's the editable editor. Emacs' malleability is at least part of the reason why it's able to stay relevant despite the fact that it has very few developers compared to Vim and other editors. Because Emacs is this way, it's potentially easier to do something dumb or install a bunch of useless, slow packages, but because Emacs is this way we also have Magit, org-mode, and a bunch of other killer packages that Vim has much worse versions of (or no equivalent of at all). This means that if you only need a simple setup, Emacs is not that appealing, but my experience has been that I have no idea what I want until I know what is actually possible (e.g. I didn't grok magit until I read the entire manual and saw how greatly it would simplify my workflow).