BTW Sending a \r (CR) on its own is a no-no in telnet, it must be followed by a \0 (NULL) if it is not followed by a \n (LF):
In RFC854 it was wrote:
The sequence "CR LF", as defined, will cause the NVT to be
positioned at the left margin of the next print line (as would,
for example, the sequence "LF CR"). However, many systems and
terminals do not treat CR and LF independently, and will have to
go to some effort to simulate their effect. (For example, some
terminals do not have a CR independent of the LF, but on such
terminals it may be possible to simulate a CR by backspacing.)
Therefore, the sequence "CR LF" must be treated as a single "new
line" character and used whenever their combined action is
intended; the sequence "CR NUL" must be used where a carriage
return alone is actually desired; and the CR character must be
avoided in other contexts. This rule gives assurance to systems
which must decide whether to perform a "new line" function or a
multiple-backspace that the TELNET stream contains a character
following a CR that will allow a rational decision.
Mind you this is a little academic in Mudlet as if there isn't a \n at the end of a line it puts it in anyhow IIRC. Which, as I have said elsewhere, is a bit awkward if the next character from the Server is a (non)-destructive backspace followed by a different character intended to animate a spinning sequence of these characters '\', '|', '/' and '-' - which one of the MUDs I have played uses!
And, if I
briefly allowed to change my Mud Client hats {it is embarrassing to do it in public but anyone using the TinTin++ forums might guess a
tiny connection I have there} - TinTin++ does have an option to separate the user input line from the Mud server output line - see the
#split command...!
