4 ms·

What’s the experience like? From memory Emacs is single threaded so curious how it performs with external IO async.

taeric 5y ago
I've never understood this criticism. Elisp is single threaded. Emacs has long had async capabilities with process buffers and sentinel functions.
- philsnow 5y ago
  UX depends heavily on the quality of the packages in your init.el; if a maintainer has gigabit fiber at home and writes their elisp to hit the network during `(interactive)` elisp, it's going to feel slow for people on worse connections. emacs/elisp aren't all that opinionated, there's lots of rope to shoot yourself in the foot with
  - taeric 5y ago
    My concern is that this will remain the case, even when Elisp goes multi threaded. Such that most concerns won't really change, at all.
- hestefisk 5y ago
  Got it, thanks for clarifying. It was not a criticism, merely curiosity. :) I used to use Emacs back in the late 90es; since then I have mainly used vi in various permutations.
  - taeric 5y ago
    Apologies if my post came off as harshe. I see this critique a lot, but it doesn't make sense to me. Especially since compilation mode has existed forever. I do grant that some things could use extra support for async, so it will be a welcome addition. But there is already a lot of capability today.
User23 5y ago
It’s like any other modern editor except it’s more easily extensible.
ReleaseCandidat 5y ago
It _is_ sluggish sometimes. It feels way less responsive than VS Code.
- TacticalCoder 5y ago
  I don't know: I'm running a "native compilation" branch of Emacs and everything is really fast. I'm not saying once in a rare while something chokes a bit but I made sure to eliminate some of the usual suspects in my init files (for example not launching lots of minor modes on gigantic files or on files with very long lines). In my experience Emacs, over the years, kept getting faster and faster. The "bloat", if any, is progressing way slower than CPU ares and certainly way slower than the bloat in other IDEs.
  - ReleaseCandidat 5y ago
    The problem isn't some 'bloat' in Emacs, but that running some processes started from Emacs almost grinds Emacs to a halt. Which always has been like that, but nowadays I start way more programs in the background. About getting faster: 27 has been the first Emacs that was usable with LSP. I've been using Emacs more than 25 years now, and can't say that it is as fast as I remember it 10 or 15 years ago (on much slower hardware), but it does have _way_ more features now.
    - taeric 5y ago
      My guess is this is mainly from the native json support. If you are using lsp, fast json will be a necessity. But the external processes is fixed with better use of async calls to other processes and tighter sentinel functions. Right?

I've never understood this criticism. Elisp is single threaded. Emacs has long had async capabilities with process buffers and sentinel functions.

philsnow 5y ago
UX depends heavily on the quality of the packages in your init.el; if a maintainer has gigabit fiber at home and writes their elisp to hit the network during `(interactive)` elisp, it's going to feel slow for people on worse connections. emacs/elisp aren't all that opinionated, there's lots of rope to shoot yourself in the foot with
- taeric 5y ago
  My concern is that this will remain the case, even when Elisp goes multi threaded. Such that most concerns won't really change, at all.
hestefisk 5y ago
Got it, thanks for clarifying. It was not a criticism, merely curiosity. :) I used to use Emacs back in the late 90es; since then I have mainly used vi in various permutations.
- taeric 5y ago
  Apologies if my post came off as harshe. I see this critique a lot, but it doesn't make sense to me. Especially since compilation mode has existed forever. I do grant that some things could use extra support for async, so it will be a welcome addition. But there is already a lot of capability today.

User23 5y ago

It’s like any other modern editor except it’s more easily extensible.

ReleaseCandidat 5y ago

It _is_ sluggish sometimes. It feels way less responsive than VS Code.

TacticalCoder 5y ago
I don't know: I'm running a "native compilation" branch of Emacs and everything is really fast. I'm not saying once in a rare while something chokes a bit but I made sure to eliminate some of the usual suspects in my init files (for example not launching lots of minor modes on gigantic files or on files with very long lines). In my experience Emacs, over the years, kept getting faster and faster. The "bloat", if any, is progressing way slower than CPU ares and certainly way slower than the bloat in other IDEs.
- ReleaseCandidat 5y ago
  The problem isn't some 'bloat' in Emacs, but that running some processes started from Emacs almost grinds Emacs to a halt. Which always has been like that, but nowadays I start way more programs in the background. About getting faster: 27 has been the first Emacs that was usable with LSP. I've been using Emacs more than 25 years now, and can't say that it is as fast as I remember it 10 or 15 years ago (on much slower hardware), but it does have _way_ more features now.
  - taeric 5y ago
    My guess is this is mainly from the native json support. If you are using lsp, fast json will be a necessity. But the external processes is fixed with better use of async calls to other processes and tighter sentinel functions. Right?