5 ms·

> Could you be more specific? At least for me, there's no noticeable lag when using Evil mode. Long-time Vim user here. I tried switching to Doom Emacs for a f

> Could you be more specific? At least for me, there's no noticeable lag when using Evil mode. Long-time Vim user here. I tried switching to Doom Emacs for a few months. I really, really wanted to like it. As a nerd, the infinite customizability is like catnip to me. It has a really mature plugin ecosystem and you can have a really comfy computing setup with magit, org mode, dired, mu4e, etc... But Emacs is intrinsically slow as molasses. The nail in the coffin for me was the scrolling performance. And I don't mean line-by-line. Even going half a page, or a full page at a time, pegs a CPU core and there is noticeable latency. The Doom Emacs documentation straight up admits it [0]. They recommend crazy things like turning off line numbers. Even with newfangled native Elisp compiler, it doesn't come even close to vim on alacritty. [0] https://github.com/hlissner/doom-emacs/blob/develop/docs/faq.org#why-is-emacsdoom-slow https://github.com/hlissner/doom-emacs/blob/develop/docs/faq...

dhagz 5y ago
I've been pretty happy with Emacs 27. I haven't noticed significant slowness with that version.
soraminazuki 5y ago
As an actual user of both editors, I have a hard time believing that scrolling performance between the two is different in a way that's recognizable. For both, scrolling is instantaneous unless 1. you spam the scroll key 2. you're viewing a exceptionally large buffer 3. syntax highlighting happens to perform badly on the buffer 4. some plugin is blocking the editor For Vim, the forth situation has vastly improved with async APIs pioneered by Neovim, but it still can happen nonetheless. As for the advice about turning off line numbers, that's just a micro-optimization. I've seen similar advice with Vim too. set nonumber nocursorline etc etc... I don't follow any of those overzealous optimization advice either on Vim or Emacs, and scrolling performance is just fine most of the time. Though for Vim, "set lazyredraw" did make a big difference in terms of scrolling performance, but that piece of advice isn't the sort that hampers usability so I don't think it really counts as an overzealous micro-optimization. But back to Emacs, my view is that general editing performance is just fine. When you think about it, if general editing performance were noticeably horrid, that would be a deal breaker for pretty much everyone. It's mostly blocking operations that's causing problems, but that's a slightly different situation from Emacs being sluggish in general. Vim used to have this problem too up until a few years ago, but it ceased to be a major source of pain after plugins adopted async APIs. I just wish Emacs would follow suite.
- pdimitar 5y ago
  On a beefy (iMac Pro) macOS workstation Emacs 27.2 is often slow at scrolling, which is also admitted in various places -- it has to do with the more pixels, apparently. Regardless of the fact that this station can also play various games at 5K resolution fairly decently... There are zero excuses for a widely used editor program to lag that badly in 2021, on very strong hardware nonetheless. One "hack" I found is to have your font not contain emojis. That was literally the only thing that actually helped. And Emacs itself isn't at fault that LSP does its thing in a synchronous manner in the same main UI thread and makes Emacs super slow. I know that. But I also know that NeoVIM does the same thing asynchronously and doesn't stutter. Sadly I'll be done with Emacs soon. I like it quite a lot but I'm not seeing any will to make it adequately fast or, at the very least, make it so its main UI thread can't be blocked. This sends a message to me that the maintainers are using Emacs in a specific way and don't care about how others are using it. Which means that it's time to part ways.
1_player 5y ago
Doom Emacs isn't Emacs. My handmade init.el was much lighter than Doom Emacs or Spacemacs ever where. Not really fair comparing a full blown setup with plugin with a barebones VIM one.
lelanthran 5y ago
> But Emacs is intrinsically slow as molasses. The nail in the coffin for me was the scrolling performance. Just to play devils advocate (in reality I'm a die-hard-never-use-anything-else vim user, and have been since 1996-ish), I did once manage to set up vim with so many highlighting and display options that I made my i7 crawl whenever I tried to scroll. (The main thing that pegged the core to 100% was ':set cul' with ':set number' and various different syntax highlighting for numbers, highlighted numbers, highlighted line, syntax-highlighting within a highlighted-line, etc). So, yeah, vim can be slow too if you nerdgasm all over the config :-)

dhagz 5y ago

I've been pretty happy with Emacs 27. I haven't noticed significant slowness with that version.

soraminazuki 5y ago

As an actual user of both editors, I have a hard time believing that scrolling performance between the two is different in a way that's recognizable. For both, scrolling is instantaneous unless 1. you spam the scroll key 2. you're viewing a exceptionally large buffer 3. syntax highlighting happens to perform badly on the buffer 4. some plugin is blocking the editor For Vim, the forth situation has vastly improved with async APIs pioneered by Neovim, but it still can happen nonetheless. As for the advice about turning off line numbers, that's just a micro-optimization. I've seen similar advice with Vim too. set nonumber nocursorline etc etc... I don't follow any of those overzealous optimization advice either on Vim or Emacs, and scrolling performance is just fine most of the time. Though for Vim, "set lazyredraw" did make a big difference in terms of scrolling performance, but that piece of advice isn't the sort that hampers usability so I don't think it really counts as an overzealous micro-optimization. But back to Emacs, my view is that general editing performance is just fine. When you think about it, if general editing performance were noticeably horrid, that would be a deal breaker for pretty much everyone. It's mostly blocking operations that's causing problems, but that's a slightly different situation from Emacs being sluggish in general. Vim used to have this problem too up until a few years ago, but it ceased to be a major source of pain after plugins adopted async APIs. I just wish Emacs would follow suite.

pdimitar 5y ago
On a beefy (iMac Pro) macOS workstation Emacs 27.2 is often slow at scrolling, which is also admitted in various places -- it has to do with the more pixels, apparently. Regardless of the fact that this station can also play various games at 5K resolution fairly decently... There are zero excuses for a widely used editor program to lag that badly in 2021, on very strong hardware nonetheless. One "hack" I found is to have your font not contain emojis. That was literally the only thing that actually helped. And Emacs itself isn't at fault that LSP does its thing in a synchronous manner in the same main UI thread and makes Emacs super slow. I know that. But I also know that NeoVIM does the same thing asynchronously and doesn't stutter. Sadly I'll be done with Emacs soon. I like it quite a lot but I'm not seeing any will to make it adequately fast or, at the very least, make it so its main UI thread can't be blocked. This sends a message to me that the maintainers are using Emacs in a specific way and don't care about how others are using it. Which means that it's time to part ways.

1_player 5y ago

Doom Emacs isn't Emacs. My handmade init.el was much lighter than Doom Emacs or Spacemacs ever where. Not really fair comparing a full blown setup with plugin with a barebones VIM one.

lelanthran 5y ago

> But Emacs is intrinsically slow as molasses. The nail in the coffin for me was the scrolling performance. Just to play devils advocate (in reality I'm a die-hard-never-use-anything-else vim user, and have been since 1996-ish), I did once manage to set up vim with so many highlighting and display options that I made my i7 crawl whenever I tried to scroll. (The main thing that pegged the core to 100% was ':set cul' with ':set number' and various different syntax highlighting for numbers, highlighted numbers, highlighted line, syntax-highlighting within a highlighted-line, etc). So, yeah, vim can be slow too if you nerdgasm all over the config :-)