> Wish something be done about proper threading support, but I understand it's a herculean task at this point.

I would agree about adding concurrency and parallelism; but threading is very much a WorseIsBetter approach, which I certainly wouldn't like to use directly.

Co-routines or futures would seem a better fit for Lispy semantics. Actors seem too different and heavyweight, but I'd still prefer them to threading!

I'm actually somewhat unclear in what the goals of threading are, at times. Pushing a process out and having a sentinel on a buffer has long been possible.

What is the aim?

Make it more light-weight and do it without needing a foreign binary. If your elisp program needs to offload some computations to a background thread, you don't want to make a binary specifically for it - it would destroy the flexibility and portability of otherwise perfectly fine elisp code.

I mean, I get this in principal. I'm curious in practice. How many things aren't already waiting on another foreign process that take time?

Edit: I could see some things like syntax highlighting being a benefit. Though, I somewhat expect those to already be moving to lsp tricks. Layout, in general, makes sense to be a bit more responsive. But I'm not clear how general threading helps with that.

Edit2: are there good benchmarks for emacs to look at and play with?

The big things are indeed being outsourced to separate processes. LSP handles a lot, I also see some attempts at moving syntax highlighting to tree-sitter[0]. But all such work means a good chunk of code is running inside a foreign process, whose behavior cannot be easily inspected or modified at runtime.

But there are a lot of various smaller things in Emacs and elisp module ecosystem that would benefit from being able to run off the main thread. Emacs performance is fighting death by a thousand cuts, with almost everything being tied to the main thread (despite async features being used to pretend it's not).

--

[0] - https://tree-sitter.github.io/tree-sitter/

The inspection and modification is a strong point that I should have considered.

I stopped using Gnus because its elisp freezes Emacs (I now use mu4e, which has a separate process).

I would guess Eww would have a similar issue, although I've never been able to get it to work (I use emacs-w3m, which has a separate process).

I've found some programming modes to be very slow and prone to freezing; most noticably Scala using Metals (which uses lsp).

Do you know what makes it freeze? My gut would be that they did not set a buffer with a sentinel, such that even with threading, they would have still don't a blocking call there.

That said, valid points. I am curious to benchmark parts of emacs now. (I turned off most programming features, since most of my code is remote and the network at home kills me.)

> Do you know what makes it freeze?

For Gnus it was using the built-in fetchers like nnrss, which would block the Emacs process until downloads finished. Using a cron job to fetch RSS feeds avoided this, but it would still take a while to check for updates even from local files. This was around 2012, so Gnus might have improved since.

FYI my current setup is described at http://chriswarbo.net/blog/2017-01-14-rss_to_maildir.html

>you don't want to make a binary specifically for it

Most of the Emacs code I've seen that spawns a process spawns a short shell script: no custom binary needed.

I said "threading" as a catch-all term. Whatever makes Emacs able to fully utilize multiple cores of a CPU would work.

I get that; which is why I call out such things when I see them (I really hate threading!) ;)