Jerror

joined 1 year ago
[–] Jerror@alien.top 1 points 1 year ago

None. Vim is zippy as shit. Emacs stutters on files an order of magnitude smaller than it takes to slow down Vim. In no small part because my Emacs is bloated but I like my Vim minimalist, but still mainly just because Vim is faster than Emacs period, and not by a little.

I don't mean no MT is a hard pass on Emacs for me obviously. But every time I pass up Emacs to use another editor it's a performance issue which multithreading would take care of handily, even if it went no further than a separate thread for the UI.

[–] Jerror@alien.top 1 points 1 year ago

None. Vim is zippy as shit. Emacs stutters on files an order of magnitude smaller than it takes to slow down Vim. In no small part because my Emacs is bloated but I like my Vim minimalist, but still mainly just because Vim is faster than Emacs period, and not by a little.

I don't mean no MT is a hard pass on Emacs for me obviously. But every time I pass up Emacs to use another editor it's a performance issue which multithreading would take care of handily, even if it went no further than a separate thread for the UI.

[–] Jerror@alien.top 1 points 1 year ago (3 children)

Every time emacs starts to chug I shrug and spin up vim. Maybe I could make that happen less often if I spent a while de-bloating and shopping around for faster packages, but as long as UI is trapped in the same thread as everything else I just don't think I can pull off the sort of optimization that'll make emacs snappy everywhere I'd like it to be. And cpu performance is ever skewing towards more cores than faster cores, at least for AMD. Emacs is underwater and still sinking, it seems; and much as I'd like to invest so many hours making it my one-stop editing shop I have no intention of going down with the ship.

But hell if emacs were multithreaded I would run EXWM

[–] Jerror@alien.top 1 points 1 year ago (5 children)

It's the biggest obstacle for sure. If we had multithreading I would go all in