Hacker News Reader

Comment by imran-iq | Hacker News Reader

Honestly the biggest blocker for me is just how slow emacs feels compared to (n)vim. Using both in a gpu accelerated terminal emulator, emacs just feels slower especially on larger files.

Granted, I have not tried to use emacs once the jit landed in 28 (or was it 29?). But it's something I really would really like to use since instead of having a different application for irc/mail/etc it could all just be emacs.

View on HN

I'm using a Macbook (intel) for work and a linux machine (xorg, not wayland) for hobby related stuff. It's insane how much snappier and instant everything feels on the linux machine. Every time I'm tinkering with my config on my private machine, I'm let down when using it on my work machine as I need to dial down things I've enabled because emacs has gotten really sluggish again.

I've read similar experiences from people all around the net, but my linux machine is also a bit more powerful than my macbook, but honestly not enough to explain the worlds of difference between the two.

Nevertheless, on both machines I've noticed a substantial speedup with the JIT you've mentioned, so maybe give it another try?

I use vmware with linux on my m1 for development because performance is so much better.

The slowness of Emacs, or lack thereof, tends to be greatly dependent on the exact configuration in use. Out of the box Emacs should be as fast or faster than any editor you wish to compare it to, but the more fancy packages you install the more likely it is to become sluggish and glitchy.

With version 29, large file support has been very much improved. Not marginally but orders of magnitudes. But differently: Editing large files is now (very) usable.

Large org files and tangling of large org files too. My literate config went from 6s to 0.25s.

Emacs is my daily driver, and even with JIT on an M1 mac I get a lot of stutter and freezes with LSP autocomplete. JIT definitely improved things [especially on my x86 machine], but I'm still unhappy with the slowness. Outside of LSP it's incredibly speedy.

I had the same issues with LSP and I switched to eglot and it's much less sluggish for me. I don't know why that is or if it's a general solution but worth giving a shot as eglot is built in I think in the newer versions.

Its because Emacs doesn't really have a way of performing asynchronous io. So lsp ends up blocking on the external server waiting for a reply.

It been the main pain point for addung smarter autocomplete for years now.

Emacs does have the ability to do non-blocking io though. Not sure if lsp-mode uses it and if not, why not.

It actually does; support for async io has been there for ages. If you've ever compiled or run git push or run an external command like M-! sleep 10 & RET from Emacs, that's using async io. For things that end up calling an external command like that, the code will typically use `start-process` or `make-process`. For network io, there is `url-retrieve` with callbacks. For tasks that need to be run via emacs-lisp (e.g. sending emails, compiling elisp), there is John Wiegley's `async` library.

However, lots of packages simply don't use these affordances.

Also, for LSP, there's additional challenges since lots of json needs parsing for each request, but IIUC Emacs can't currently process the messages to/from the server while the UI thread is busy (the LSP server can do lots of work while UI is busy, but the communication is stalled until UI is done). Though it seems things will be improving there, hopefully this'll get upstreamed soon: https://www.reddit.com/r/emacs/comments/ymrkyn/async_nonbloc...

I use both Emacs 28 with native compilation and Nvim with Neovide.

Emacs is not as snappy obviously. But it doesn't lags either. It's just not fast.

Reply on news.ycombinator.com