4 ms·
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.
by skydhash 8mo 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 8mo agoSure, but why would you intentionally make such a slow and buggy editor? I don't buy the idea that this is on purpose.
- skydhash 8mo agoYou’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 8mo agoI'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 8mo 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