4 ms·
Isn't cursor keys like that? If you get stalls when it sends the 4-5 byte sequence, you get to see ]^A instead of cursor moving. Having dog slow links and tcp
by IcePic 7y ago
Isn't cursor keys like that? If you get stalls when it sends the 4-5 byte sequence, you get to see ]^A instead of cursor moving.
Having dog slow links and tcp set to send each char instead of waiting for a whole line or packet probably helps to see it, but I'm somewhat certain the whole code for a cursor movement needs to arrive within a certain time in order for it to actually be a movement and not the individual chars.
- nineteen999 7y agoSounds like you might be dealing with a particular implementation quirk, or perhaps with SSH or some other network transport issue. In general terminal emulators tend to implement control character processing with a state machine: https://vt100.net/emu/dec_ansi_parser https://vt100.net/emu/dec_ansi_parser In theory that shouldn't be affected by latency or delay in processing characters or groups of characters, and should be independent of the line speed, after all, the VT100 was able to operate at speeds between 50bits/second and 19,200 bits/second. https://en.wikipedia.org/wiki/VT100 https://en.wikipedia.org/wiki/VT100 That said, there are so many terminal emulators out there (xterm, gnome-terminal, linux console, just to name a few) and so many potential transport protocols (telnet, SSH, serial etc) and modern pty layers to deal with as well, so there are bound to be differences/quirks with different combinations.