> Certain points like the fact that Emacs isn't multithreaded are thrown around by people who don't have the intuition that multithreading isn't the right thing for a lot of applications. The added complexity that multithreading would add to Emacs would seriously outweigh the usefulness it would provide. Emacs already has a decent process model, and having to deal with only a single shared state makes programs much cleaner.
I theoretically understand this but having to deal with company-mode providers that, when they start performing badly, start hanging everything is not fun!
Obviously thread-count and async-codestyle-ease are not the same thing, but given the world of LSPs and plugins that do I/O on the main thread (this is a big enough reason to have async interfaces that are actually used) it would be good to have some effort spent there
Yes, on the particular issue of company/corfu, I'm actually tempted to see if we can't just specify that the work of `completion-at-point-functions` must be done in an external process. Then calling `completion-at-point` would never directly call third-party code that may block the main thread.
Maybe for speed, `completion-at-point` would keep a fairly recent `dump-emacs-portable` image, and spin up external processes using that, with has the bonus that the completion-at-point-functions get to inspect current state.
I'm curious what makes you so sure those plugins will actually use multithreading appropriately? Emacs already has methods to communicate with processes off the main thread, right?
So some of this stuff is "communicate with an external process", and I feel like many things in that space do the right thing (if only because if you don't it's immediately visible).
I have a lot of issues with "pure elisp" plugins though. Things where these plugins are doing a lot of string munging, and it's fast in testing because the tests aren't that big. But you can easily hit some edge case where suddenly you're looking for occurrences of `e` in Moby Dick so now each letter press takes a second (fortunately computers are still fast!)
If completion frameworks were async-by-default, at least that stuff wouldn't hang everything for me. At least that's my theory.
Makes sense. Auto complete things are increasingly using language servers, such that I would think they should be in the "communicate with an external process" category. Right?
For pure elisp, the worst I have seen have been around gigantic org buffers. Which, isn't too hard to split up into smaller buffers.
By far the worst case of slowdown is in gigantic log files with absurdly long lines. They made a lot of headway there in detecting the case, as I recall. I also don't think anyone ever said multithreaded would help there.
I theoretically understand this but having to deal with company-mode providers that, when they start performing badly, start hanging everything is not fun!
Obviously thread-count and async-codestyle-ease are not the same thing, but given the world of LSPs and plugins that do I/O on the main thread (this is a big enough reason to have async interfaces that are actually used) it would be good to have some effort spent there