Post #3209114

@screwlisp@gamerplus.org @dougmerritt@mathstodon.xyz In my experience, what matters about a text editor is the editing substrate, not the display. While there is room to do a lot of interesting stuff with display, for the most part Emacs works (at least in the era I was familiar with, and also in Zmacs) by presuming that display will mostly take care of itself, and that it's merely important to update the buffer structures. In fact, TECO-based Emacs commands did worry heavily about telling the caller what part of the buffer changed, so that it could optimize the redisplay to what would have affected only what in modern window systems would be the clipped region of a window/viewport, but in those days was a tiny rectangle of screen allocated more directly (at least for TECO-based Emacs). Even the Lisp Machine focused pretty heavily on data structures that were linked line structures so that if the buffer was long, only the region in view the links between the start line and the end line would need to be considered, thus making it possible to edit long files (as long as they had frequent newlines) without substantial O(n) cost. I'll talk to you privately about whether we can find a time. But I should add that NEX was built on Emacs as just a set of customizations. It was packaged in a finished way as a full editor. But it was not a separated effort in the way some other command sets for Emacs were. Though the way Emacs was built, like the way the modern one is, it was still possible to load all that support into others' editors, and just not run the command that would make it set itself up as dominant. So it's hard to tell if that difference matters.