Hi! Interesting, how do other telnet clients behave wrt to this? Is your suggested solution implemented by any other client? I'm not sure if we should introduce a implementation difference like this without serious consideration and (attempts to) discussion with other implementers.
/Simon [email protected] writes: > Hi! > > > I recently came across an ancient issue related to the ambiguity in > interpreting > the escape key in terminal applications. The problem lies in > distinguishing the > escape key "\x1b" from ANSI escape sequences (e.g., "\x1b[A" for the > up arrow). > > Traditionally, this issue has been addressed by measuring the time gap > between > receiving the initial escape character "\x1b" and the following > "[A". If there > is a noticeable delay between them, they are considered as separate > keys (ESC, > '[', and 'A'). Otherwise, they are treated as a single up arrow key > press. > > While this time-based approach works well for locally executed terminal > applications, telnet applications are still affected by network > latency issues. > > To tackle this, I suggest enabling the negotiation of the Telnet End > of Record > Option in the Inetutils telnet client. Currently, the client does not > seem to > support this option effectively. Although some handling exists in the > source > code, it appears to be activated only when the TN3270 macro is defined. > > If the telnet client could send an IAC EOR 2-octet sequence after each > key > press, the ambiguity could be easily resolved, at least in character > mode > transmission. > > > Erich > >
signature.asc
Description: PGP signature
