The Emacs dumper dispute [LWN.net]

The Emacs dumper dispute

Posted Dec 1, 2016 4:55 UTC (Thu) by zblaxell (subscriber, #26385)
In reply to: The Emacs dumper dispute by jlargentaye
Parent article: The Emacs dumper dispute

I am completely mystified about why the second half of the article isn't

"...so we spawn a second thread in main() which emulates exactly the terminal IO model Emacs was designed for. Every 16.7ms, this thread takes a snapshot of what Emacs has written on its frames so far, renders the text in a backbuffer, and swaps buffers with the display frontbuffer (unless the frames haven't changed and we don't have any Expose events to deal with). Emacs updates its frames whenever the hell it wants and nobody bothers Emacs to do anything it doesn't want to. Then we walked through all the #ifdef five-toolkits mess and just deleted it. You're welcome."

In this century we have smartphones that can render a screen full of text faster than the monitor refresh rate while digitally emulating in real time the electron-beam distortions that text would encounter as it passes through the analog electronics of a vintage 1980's CRT. It sounds like this Emacs hack is solving the problem the Emacs way instead of the sane way.

I suspect the solution to the mystery is going to be another level of mystery (I think the first level of that might be "OK so threads and unexec don't get along well, but why did anyone think unexec was the best of several potential alternative solutions, even at the time?"), recursively descending until one of us shouts "you people are crazy" and storms out of the room.

the sort of thing that could give vi a definitive advantage in the interminable editor wars

This is a serious misunderstanding of the editor wars. The alternative is not the other editor. The alternative is downgrading glibc.

to post comments

The Emacs dumper dispute

Posted Dec 1, 2016 7:17 UTC (Thu) by smurf (subscriber, #17840) [Link] (1 responses)

Because Emacs is a complex beast which frequently requires more that .02 seconds to render a complex buffer, and you don't want a half-written frame to show up on your screen. Ever.

Suppose you do horizontal scrolling. You don't want the top part of your buffer to be to the right of the bottom part. Not even for 1/60th of a second.

Yes, power users care about that sort of thing. Yes, it can be noticeable, even at that speed.

The Emacs dumper dispute

Posted Dec 2, 2016 3:48 UTC (Fri) by zblaxell (subscriber, #26385) [Link]

Odd, I thought the point of using a museum piece as a text editor was to get the vintage green-scrolling-text-at-19200-baud feel without the decade-later vintage NCD-xterm-flickering-display-update horror. If you wanted smooth horizontal scrolling, why were you using Emacs?

Seriously, though, in the world outside of Emacs it would be much easier to have the elisp thread ping the render thread to say "ok now is/is not a good time to take your screenshot away for rendering" than to try to get a single thread to run elisp, push updates at the display refresh rate, and avoid burning resources on unnecessary rendering. The original Emacs design assumed those things would be done on a dedicated external processor, not embedded in the REP loop.

Apart from anything else it's a waste of CPU cores to only use one. The rendering task takes a few milliseconds, and waiting for rendering will burn time Emacs could be spending on deciding what to display next.

The Emacs dumper dispute

Posted Dec 2, 2016 2:22 UTC (Fri) by da4089 (subscriber, #1195) [Link]

If Emacs were to grow its own libc implementation, that would solve not only this problem, but potentially others in future as well!