> 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.
GNU Emacs has a lot of applications where it is the right thing. It's no longer the simple editor. It comes with more than a million lines of Lisp code implementing all kinds of complex features: like various network client applications, IDEs, ...
> Common Lisp+SLIME shares some of this convenience, but not to the extent that Elisp truly does
SLIME is mostly implemented in Emacs Lisp. A lot of other Lisp systems can locate all source code and all documentation. It's not so much a special feature of Emacs Lisp, but its development environment. It's also not necessary that the IDE and Lisp runs in the same process / same machine to be able to look up documentation and code. It may be convenient in GNU Emacs, but any such editor can provide such features for programming language implementations.
> GNU Emacs has a lot of applications where it is the right thing. It's no longer the simple editor. It comes with more than a million lines of Lisp code implementing all kinds of complex features: like various network client applications, IDEs, ...
I experimented with that, but it doesn't use more than one CPU core, so it's more of a proof of concept at the moment.
You could use it to make non-blocking user experience perhaps, but you could also do it using `while-no-input` or a library like deferred.el or my https://github.com/meedstrom/asyncloop.
Anyway, there is `make-process` for multicore work. Takes some boilerplate and studying, but no more than with threads.
Yes, that runs Common Lisp code in an external Common Lisp instance via a SLIME / SLY connection, using the CL thread features. It can use Bordeaux-Threads as API for threads in various CL implementations.
https://github.com/sionescu/bordeaux-threads
GNU Emacs has a lot of applications where it is the right thing. It's no longer the simple editor. It comes with more than a million lines of Lisp code implementing all kinds of complex features: like various network client applications, IDEs, ...
> Common Lisp+SLIME shares some of this convenience, but not to the extent that Elisp truly does
SLIME is mostly implemented in Emacs Lisp. A lot of other Lisp systems can locate all source code and all documentation. It's not so much a special feature of Emacs Lisp, but its development environment. It's also not necessary that the IDE and Lisp runs in the same process / same machine to be able to look up documentation and code. It may be convenient in GNU Emacs, but any such editor can provide such features for programming language implementations.