3 ms·

This seems really interesting from a technical point of view. However, they seem to be assuming that developers will place a very high value on low input lag. T

by foldr 5y ago

This seems really interesting from a technical point of view. However, they seem to be assuming that developers will place a very high value on low input lag. This seems especially doubtful in the context of a collaborative editing tool, where network delays are likely to dwarf any input lag deriving from the event handling and rendering architecture of the editor. This leaves me wondering what the key advantage of this product will be over VSCode Live Share.

samuell 5y ago
I guess not everything would need to lag. As long as you and your peers are working on not the exact same row, a slight network delay might not matter too much, especially if your own typing etc doesn't lag?
- dilap 5y ago
  Yes, exactly. You should be able to show your own input immediately. For others input, you can't tell the difference between human lag and network lag, provided the network lag is reasonably low (which it will be unless you have a very bad or super-high-latency network).
dilap 5y ago
As looooong time user(/addict) of emacs, probably my two biggest complaints are slowness and bugginess. So I find an absolute focus on speed to be quite appealing. I 100% agree with their philosophical positions: An editor should always be able to reflect input in the next screen refresh. This might seem like a trivial thing to care about, but things that are more responsive just feel better to use. For something that I use all the time (too much, really), that's very significant. (And w/r/t the network case, you still show your local input immediately; of course, input from other players is necessarily lagged, but you don't care about that.)
- foldr 5y ago
  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.
  - dilap 5y ago
    > 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.
    - foldr 5y ago
      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?)

by foldr 5y ago

samuell 5y ago

I guess not everything would need to lag. As long as you and your peers are working on not the exact same row, a slight network delay might not matter too much, especially if your own typing etc doesn't lag?

dilap 5y ago
Yes, exactly. You should be able to show your own input immediately. For others input, you can't tell the difference between human lag and network lag, provided the network lag is reasonably low (which it will be unless you have a very bad or super-high-latency network).

dilap 5y ago

As looooong time user(/addict) of emacs, probably my two biggest complaints are slowness and bugginess. So I find an absolute focus on speed to be quite appealing. I 100% agree with their philosophical positions: An editor should always be able to reflect input in the next screen refresh. This might seem like a trivial thing to care about, but things that are more responsive just feel better to use. For something that I use all the time (too much, really), that's very significant. (And w/r/t the network case, you still show your local input immediately; of course, input from other players is necessarily lagged, but you don't care about that.)

foldr 5y ago
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.
- dilap 5y ago
  > 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.
  - foldr 5y ago
    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?)