[net.info-terms] terminal emulators and invalid ESC sequence

nadji@uscvax.UUCP (Behzad Nadji) (12/28/85)

What is a terminal emulator supposed to do when it receives an 
invalid escape sequence. For example, what should a VT52 emulator 
do when it receives an <Esc>M or <Esc>X ?

  1- Ignore the sequence.
  2- Write it to screen as it is.
  3- Ignore the sequence, but indicate an error (by a beep or by writing a
                 block (?) character to screen).
  4- Write it to screen as it is, but indicate an error as above.
  5- others?

Choices 3 and 4 sound awful; 1 is ok but may cause problems if the actual 
text being received contains the <Esc> character. My choice has been 2 but 
I was wondering if anyone knows what the standard is. 

                              ARPA:     nadji%usc-cse@csnet-relay.arpa
                              CSNET:    nadji@usc-cse.csnet

ac4@pucc-j (Tom Putnam) (01/03/86)

In article <171@uscvax.UUCP> nadji@uscvax.UUCP (Behzad Nadji) writes:
>What is a terminal emulator supposed to do when it receives an 
>invalid escape sequence? 

I wrote a terminal emulator and had to deal with this question.  I think
there are two answers:

  1) Ignore the sequence.  The "typical" user doesn't care unless it is a
     sequence that invokes a function that he needs.  If you don't support
     that function for some reason (incomplete emulation), then your user
     isn't going to be any happier if you tell him about it.

  2) Provide a debug mode where you ignore the sequence but tell the user
     about it.  My terminal emulator uses the 25th line of the display to
     flash such messages for about 3 seconds.  I have found it is quite
     useful in debugging not only my emulator but also debugging the
     various terminal packages and systems I use it with.  I use the 25th
     line as a temporary status line (window?).  You can save it and restore
     it if necessary to provide complete emulation capabilities.  Be sure to
     include the full text of the escape sequence in the message - easy
     enough to do since you don't have to deal with non-printing control
     characters.
-- 
Tom Putnam, Manager of User Services
Purdue University Computing Center

ARPANET: ac4@asc.Purdue.EDU
     or  ac4@purdue-asc.ARPA
BITNET:  PUTNAMT@PURCCVM
CSNET:   ac4@purdue-asc-tn
USENET:  ac4@pucc-j.UUCP
USMAIL:  Mathematical Sciences Bldg.
	 West Lafayette, IN 47907
PHONE:	 317/494-1787