Input lag has been imperceptible for me with all text editors that I've ever seriously used for coding (Vim, Emacs and VSCode). I appreciate that some people are genuinely more sensitive to input lag than others. However, I have to suspect that it's a minority concern. It doesn't seem like the first thing to mention on a marketing page.
>of course, input from other players is necessarily lagged, but you don't care about that
But I do care about network lag. It's a much greater source of inconvenience (to me) than an imperceptible (to me) lag in registering my key presses.
> But I do care about network lag. It's a much greater source of inconvenience (to me) than an imperceptible (to me) lag in registering my key presses.
With a clever implementation, you should see your local input reflected instantly, and other people's input will arrive with some delay. However, since you don't actually know when other people started the input, as long as you have a reasonably fast network, it should be "imperceptible" to you. (There's nothing to perceive!)
> Input lag has been imperceptible for me with all text editors that I've ever seriously used for coding
Here's a very specific example: try using emacs to edit the the c++ source file for the c# thrift generator. For extra agony, try using the iedit emacs extension to change a symbol throughout the file. It's extremely laggy.
Emacs in fundamental mode without any extensions is responsive.
> I appreciate that some people are genuinely more sensitive to input lag than others. However, I have to suspect that it's a minority concern.
Different strokes for different folks! I for one am happy to see an editor with that focus. (We'll see if it lives up to it!)
I also have a theory that even people that think they aren't sensitive to input lag actually might be -- I'd love to do some sort of study where people are divided into two groups to do some editing task for 8 hours, one group with an editor that deliberately has say a 100ms delay in input processing vs one group that doesn't, and afterwords survey each group about emotional state, fatigue, etc.
> For extra agony, try using the iedit emacs extension to change a symbol throughout the file. It's extremely laggy.
The buffer data structure that Emacs uses -- a gap buffer -- has a fundamental incompatibility with making multiple "simultaneous" edits. Any attempt to do it in Elisp is going to be hacking (in a good way) around that. Performance will definitely degrade for a large buffer, because it has copy around most of the buffer contents for each edit. Full explanation here if you're curious: https://nullprogram.com/blog/2017/09/07/
Tangential, but I definitely disagree w/ the blog post about the value of multiple cursors vs just macros and rectangle edits, tho. Multiple cursors are just so much easier to work with and get right. You're editing blind when recording a macro, which is tricky, and if you mess up, you have to start over again from zero.
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.
(By the way, I am fully aware that there need not be any delay in showing one's own input locally. That does not mean that network lag ceases to be an issue when editing collaboratively. It just means that you can speculatively display the probable result of your own edits before you've synced with the other person's edits.)
Apart from that, of course you are right that it is just a question of how many people find input lag to be a significant problem in their current text editor of choice. 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?)
> 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. :-)
I've personally noticed an ever increasing responsiveness throughout Emacs since switching to the native compilation versions in the early pandemic. I have an Ethernet connection with a 2ms ping for my typical remote Emacs sessions and I feel the difference when I occasionally have to work from faraway locations or through fluctuating WiFi networks that add another 30ms on top. Some colleagues use mosh as their terminal to improve the experience in the presence of lag.
>of course, input from other players is necessarily lagged, but you don't care about that
But I do care about network lag. It's a much greater source of inconvenience (to me) than an imperceptible (to me) lag in registering my key presses.