From: Daniel Colascione <address@hidden>
Date: Sun, 30 Oct 2016 15:49:02 -0700
Cc: address@hidden
Agreed. That's basically how IntelliJ works too. We can do even better too:
there's no reason these parts need to run in the same process it even the same
machine.
I think we should be careful when comparing Emacs with systems that
have a different basic design. In Emacs, almost everything is driven
by changes in buffer text and the data structures that accompany
buffer text, and the Lisp interpreter is inherent in many
display-related features.
For example, this:
But this scheme won't really eliminate the coupling between redisplay and lisp
though, since the former calls into the latter. The redisplay thread has to
block waiting on lisp anyway.
is a major issue that those other systems might not have.
Anyway, I strongly encourage you to look at the React Native rendering model.
It's the most elegant way I've seen of constructing GUIs in general.
Where's that model described in enough technical detail to be able to
compare it with what we do in Emacs?
The key insight there is that we shouldn't have redisplay *lock* the display
matrix and render it. The lisp universe should send a *copy* of the matrix set,
then go about its business. This way, redisplay can go display that copy and
everything is decoupled. You turn the system into an Erlang like message
passing environment.
There's probably some confusion or misunderstanding here: the Lisp
code in Emacs has no access to the glyph matrices, so it does not (and
cannot) "send the display matrix" to the display engine. Thus, the
fact that the display engine can lock the glyph matrices is due to its
being their sole writer and reader. The communication between the
Lisp universe and the display engine is solely via the buffer text and
the auxiliary data structures (text properties, overlays, etc.).