Re: telnet client enhancement proposal

Simon Josefsson via Bug reports for the GNU Internet utilities <[email protected]> Mon, 12 Jan 2026 08:56:12 +0100

Newsgroups	gmane.comp.gnu.inetutils.bugs
Message-ID	<[email protected]>

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 (application/pgp-signature, 1.2 KB)