Re: Gap buffer problem?

[Eli Zaretskii]

> Date: Wed, 11 Dec 2024 19:54:07 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: gerd.moellmann@gmail.com, emacs-devel@gnu.org, ofv@wanadoo.es
> 
> "Eli Zaretskii" <eliz@gnu.org> writes:
> 
> > Anyway, the fact that redisplay calls Lisp and Lisp calls back into
> > redisplay all but kills this idea.  Gerd's document has also other
> > gotchas.  We didn't just give up easily back when we discussed that.
> 
> I don't see why the redisplay process would not be able to call Lisp;
> it's a full Emacs process (with a single thread)

So you are going to fork on each redisplay?

And how will you pass back the results of Lisp evaluation, if the
other process meanwhile changes the global state (as it's running
concurrently)?

> except it doesn't have
> an FD or socket for the window system, and has an extra pipe to
> communicate with the parent process instead.

Do you have an estimation of the throughput that such a pipe will need
to handle in order to support GUI display?  What will you send through
the pipe?  If you send only some kind of commands, then the other
process will need to generate the font glyphs in some way -- the same
glyphs that the "redisplay" process already produced.  And if you
intend to send the pixels, that would be too much traffic, I think.
And again, the global state of the receiving process could have
changed, which means any high-level data might be useless (e.g., using
a font that was unloaded).

> It's true that the side effects of the called Lisp code won't be visible
> to the next redisplay process, but such side effects are perilous
> anyway, and avoiding them would seem to me to be a feature, not a bug.

In Emacs, they are a feature, and are expected to work.  You'd be
surprised to see how many packages and user code rely on that.

> But, to be perfectly honest, I'm not sure redisplay is slowing me down
> the way traditional GC is.

It's the other way around: the Lisp machine blocks user interaction,
including the UI and display.