Value of escape

[eppick77]

I have noticed over the years that on some systems the value of escape
was 251 and on others it was 27. It is 27 on QM to my knowledge.

Does anyone have any background history on the reason for this?

Just curious.

Eugene

[Martin Phillips]

Hi Eugene,

> I have noticed over the years that on some systems the value of
> escape was 251 and on others it was 27. It is 27 on QM to my
> knowledge.
>
> Does anyone have any background history on the reason for this?

The ASCII character set defines the escape key as sending character 27 and
much software relies on this. Most modern terminal emulators allow you to
change the characters sent by specific keys so perhaps this is why you have
seen 251.

Within the multivalue world, character 251 is the text mark.

Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB
+44-(0)1604-709200

[pschellenbach]

Hi Eugene -

On D3 (and AP, R83 and R77 before it), the common terminal input
routine used by TCL and BASIC translates certain control characters to
system delimiters. Specifically (hex) 1E, 1D, 1C and 1B are translated
to FE, FD, FC and FB on input and to 5E, 5D, 5C and 5B on output. I
suppose the intention is to make it simple to enter system delimiter
characters from the terminal. ESC is truly 27 (1B), but translated to
251 (FB) by the input routine on the host. If you use the IN statement
on D3 or KEYIN function on QM, you will get the actual value of the
ESC key.

Thanks,

Peter Schellenbach

[eppick77]

What I was doing was INPUT CMD,1. I would then check to see if it was
an escape and then check for the next command.

However, on some systems like Ultimate, I would have to have it as 27
and on some it had to be 251.

I appreciate the information as to why this is the case.

Eugene

[Tony G]

Eugene, I didn't know exactly what you were looking for, so
didn't offer any comment before.

If you get ESC=27, then you really do have an escape char. It's
a single byte which is transmitted from client to server, the
server gets it, processes it, no problem.

For some cursor and function keys (by default) an escape plus
another char is generated. When the server gets an ESC, how does
it know if the next character is to be processed separately, or
if the first character is the high-end of a two-byte function
key/arrow sequence? Because of timing issues, the server may
receive the escape before the next char, process that as a single
character, and the following character will get processed as some
rogue non-printable. Google for ESCDELAY and you'll see that
this issue isn't unique to D3.

If you're capturing input and echoing it back with SEQ commands,
you want to know when you get a single ESC and when you get a
multibyte sequence. If you're processing a saved the data stream
(not in an Input loop but maybe parsing characters received from
a prior input session), you don't want to see just a bunch of ESC
chars. Your code needs to know whether it's going to process an
ESC or whether it needs to process a couple bytes to execute a
cursor function.

So somewhere in the D3 telnet server, between the socket recv()
and right before the data is returned into your input buffer, the
first byte is translated to something that the user can't enter
on their own, a 251. And when you see that, you know it's not
single byte ESC=27 but ESC plus something else that was received
within about 500ms after the first byte.

HTH
T

From Eugene:

[Martin Phillips]

Hi Tony,

> For some cursor and function keys (by default) an escape plus

Just in case you haven't noticed it, QM's KEYCODE() function distinguishes
between a lone escape key and multi-byte sequences that start with escape by
using a short delay much as you suggest.

[Tony G]

Thanks for the info, Martin. It's good that QM has an
alternative option.

Personally I use AccuTerm to map function and arrow keys for SED,
TCL, etc. So I'm not using any of this functionality, just
explaining how (I believe through observation) it works.

T