4 ms·
> Fun fact about terminal escape sequences: some of them are timing-dependent. If a byte arrives too slowly, it will do something different As someone working
by nineteen999 7y ago
> Fun fact about terminal escape sequences: some of them are timing-dependent. If a byte arrives too slowly, it will do something different
As someone working on a couple of different VT100 emulations, can you provide an example of this? I'm curious now, as none of the specifications I've seen mention this that I can think of off the top of my head.
- IcePic 7y agoIsn'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.