> Network lag in a collaborative editing environment definitely is perceptible in practice. Though in theory you can't be 100% sure that the other person isn't

> Network lag in a collaborative editing environment definitely is perceptible in practice. Though in theory you can't be 100% sure that the other person isn't just pausing randomly in the middle of typing a word, the statistical signature of lagged typing is quite distinctly perceptible. If we imagine all possible network conditions, this is definitely true for some of them. But if you have a good network, I don't think you're going to be able to tell. Consider that you can even do something like Stadia which does round-trip input lag to render a full-frame of a video game, and it often works pretty darn well. Something like the one-way lag between when another person starts typing (an event you can't know the start of) and when it arrives on your display just isn't going to be noticeable if you're both on at all reasonable network connections, imo. > The issues with Emacs, as you note, have to do with the low performance of various language modes rather than the rendering architecture of the editor. (Though I guess maybe there is some missed opportunity for parallelism imposed by Emacs's architecture?) Yes and yes. (Also, it's a contributor to the bugginess of emacs -- dynamically typed and (often) dynamically scoped(!) lisp code is not conducive correctness. It does, however, lend itself amazingly well to extensibility/flexibility.) So but anyway, plain emacs w/ no language modes is indeed fast and fairly bug free, but...what's the point? The goal is to be able to have a full-featured editor that remains fast and bug-free. :-)