在 2020年1月1日 +0800 AM12:36，Eli Zaretskii <eliz@gnu.org>，写道：
The Lisp interpreter already sort-of "queues" display changes, because
it only changes Lisp data structures, and then the display engine
references those data structures at display time. So those data
structures serve as a kind-of "queue", since redisplay runs when Emacs
is idle (i.e., the last Lisp command completed its job).
But the problem is in the other direction: it's not that Lisp somehow
"drives" the UI, it's that the UI frequently calls into Lisp as part
of its job. The simplest example is mode-line format: it includes
references to variables, and can also include :eval forms that call
the interpreter.
It is much clearer to me now. We can keep them all as the UI thread.
Your idea in fact means to have several isolated Lisp machines in the
same process. But how can we do something like that without a very
radical redesign of Emacs, when so many things in Emacs are implicitly
part of the global state? Buffers, global variables, windows,
frames--all those are global resources, and every thread will want to
access them. Emacs was not designed to allow that.
All those global resources are not accessible by workers. Workers can only access network, file system and other non-global resources. They only do the following things:
1. retrieve content from network, parse the data, and send the result(lisp data) to the UI thread to present it
2. communicate with subprocesses, parse the data from subprocesses, and send the result to the UI thread
3. do file indexing and send the index result to the UI thread
4. do other heavy work like mathematicl calculation and deep learning, send the result to the UI thread
Let the UI thread do as less work as possible.
Your idea can be implemented with two processes, though. And there is
already a package called emacs-async which does that:
https://github.com/jwiegley/emacs-async
I knew this package. It is a good idea. Modern web browsers also use separate processes to render page content(one or more pages per process). They design specific IPC to let the worker processes to communicate with the main(UI) process. They have good performance and good user responsiveness.
I think emacs is much like web browsers. Both render large text content and care user responsiveness. We can learn from them.
The disadvantage is that it is cumbersome to share data between the
two instances of Emacs, and large amounts of data will make that
inefficient.
We may design an IPC for their communication.