6 ms·

I don't think your complaints are a common experience. I've used neovim for the last 10 years, but before that I used emacs with R for many years at work and i

I don't think your complaints are a common experience. I've used neovim for the last 10 years, but before that I used emacs with R for many years at work and it was great, certainly not slow.

throwaway27448 6mo ago
Emacs is certainly capable of speedy editing; i don't mean to imply otherwise. But there isn't much explanation as to why emacs does things the way it does even if it makes the experience shittier.
- skydhash 6mo ago
  There is just one explanation. The people who develop it like it this way and unless you want to pitch in, your very vague complaints does not really matter.
  - throwaway27448 6mo ago
    Sure, but why would you intentionally make such a slow and buggy editor? I don't buy the idea that this is on purpose.
    - skydhash 6mo ago
      You’re maybe trolling. But what exactly is slow? Or are you a superhuman typing 400 words a minute? Emacs have never crashed on me (I use it daily) and there are things you just can’t speed up. Multithreading just sidesteps the problem while introducing its own can of worms. The current async facilities are fine by me (I don’t use any auto* things, so YMMV).
      - throwaway27448 6mo ago
        I'm not trolling. How long does it take to start emacs for you? > Multithreading just sidesteps the problem while introducing its own can of worms. In the meantime we're all stuck waiting for package downloads. I don't know the specifics about why emacs can't move to a concurrent model but it's embarrassing at this point > The current async facilities are fine by me (I don’t use any auto* things, so YMMV). Yes, it is clear the people who maintain emacs are fine with it. This is why using emacs in 2026 is so shitty.
        karthink 6mo ago
        > In the meantime we're all stuck waiting for package downloads. I use Elpaca instead of the built-in package manager, which is better designed (declarative package specification) and fully asynchronous. The UI is also more thoughtful, with more granular search-as-you-type capability and easy git commit reviews of pending package updates. package.el is catching up to Elpaca in features, but async installs/updates is not one of them. https://github.com/progfolio/elpaca https://github.com/progfolio/elpaca

I don't think your complaints are a common experience. I've used neovim for the last 10 years, but before that I used emacs with R for many years at work and it was great, certainly not slow.

throwaway27448 6mo ago

Emacs is certainly capable of speedy editing; i don't mean to imply otherwise. But there isn't much explanation as to why emacs does things the way it does even if it makes the experience shittier.

skydhash 6mo ago
There is just one explanation. The people who develop it like it this way and unless you want to pitch in, your very vague complaints does not really matter.
- throwaway27448 6mo ago
  Sure, but why would you intentionally make such a slow and buggy editor? I don't buy the idea that this is on purpose.
  - skydhash 6mo ago
    You’re maybe trolling. But what exactly is slow? Or are you a superhuman typing 400 words a minute? Emacs have never crashed on me (I use it daily) and there are things you just can’t speed up. Multithreading just sidesteps the problem while introducing its own can of worms. The current async facilities are fine by me (I don’t use any auto* things, so YMMV).
    - throwaway27448 6mo ago
      I'm not trolling. How long does it take to start emacs for you? > Multithreading just sidesteps the problem while introducing its own can of worms. In the meantime we're all stuck waiting for package downloads. I don't know the specifics about why emacs can't move to a concurrent model but it's embarrassing at this point > The current async facilities are fine by me (I don’t use any auto* things, so YMMV). Yes, it is clear the people who maintain emacs are fine with it. This is why using emacs in 2026 is so shitty.
      - karthink 6mo ago
        > In the meantime we're all stuck waiting for package downloads. I use Elpaca instead of the built-in package manager, which is better designed (declarative package specification) and fully asynchronous. The UI is also more thoughtful, with more granular search-as-you-type capability and easy git commit reviews of pending package updates. package.el is catching up to Elpaca in features, but async installs/updates is not one of them. https://github.com/progfolio/elpaca https://github.com/progfolio/elpaca