🚀 go-pugleaf

        Here's a question for the real TPU "internals" experts and
    gurus:

        How can I get EVE (TPU) to recognize a given, semi-
        arbitrary, escape sequence sent by a terminal?  And
        how can I define a new KEYWORD for TPU?

        Alright, I know, I can't do either :-(  But the issue involves
    the KEY_NAME built-in, it's actual behaviour vs. its documented
    behaviour, and a certain change in going from TPU in VMS V4.7 (yeah,
    really!) to VMS V5.x.  Current situation: VMS V5.5-1, TPU V2.6.

        OK, among the other oddities around here, we have scores of
    Ann Arbor Ambassador and Ann Arbor Ambassador XL terminals.  These
    are ANSI and support most VT100 DEC private escape sequences.  Thus
    I've been able to add EVE keymaps for these terminals.  This they
    have LOTS of function keys, editing keys, keypad keys up the wazzoo,
    :-0  and most of these keys are programmable from the host, I've been
    able to program the keys to send escape sequences that TPU
    recognizes, e.g. "ESC [ 65 ~".

        Under V4.7, I created a bunch of integer variables that
    corresponded to these "made-up" keys, and use those variables in the
    DEFINE_KEY calls.  In fact, those integers are unchanged in the
    current version: you get them through, e.g. INT(E6_KEY).  The
    supported way of doing this now is to use the KEY_NAME function to
    return a keyname keyword.  For example, to recognize "ESC [ 65 ~",
    one would do:

        	    F65 := KEY_NAME (65, FUNCTION);

    Nice.  Similarly, I have used  SHFT_TAB_KEY := KEY_NAME (90, KEYPAD)
    to generate a keyname keyword for "ESC [ Z" (90 is the ascii for Z).

        WHAT!  The doc's say that the KEYPAD keyword used with KEY_NAME
    should create a keyname that corresponds to "ESC O" followed by the
    character specified in KEY_NAME call, not "ESC [".  Don't get me
    wrong, I'm HAPPY it works this way, I just don't understand what's
    going on internally in TPU.

        However, I'm NOT happy about the other half of this change from
    old to new:  One of the ambassador keys sends "ESC c", no "O" or "["
    following the escape.  And because of history, I can't reprogram
    this key just to make TPU happy.  Under V4.7, I did the following:

        AMB_RESET_KEY:=  1090544384;  ! Ambassador RESET key is ESC c
                                      ! (or ESC [ c), 41006300 in hexadecimal

    Then I used AMB_RESET_KEY in KEY_NAME calls.  Of course, in V5.5-1,
    the KEY_NAME functions requires a KEYWORD or KEYWORD variable as the
    second parameter and rejects an integer variable if you try :-(
    Instead I do AMB_RESET_KEY := KEY_NAME (99, KEYPAD), which, BTW,
    does give INT(AMB_RESET_KEY) = '41006300'X.

        However, when I _type_ the reset key on the Ambassador, TPU
    gives the error message:

              %TPU-W-UNKESCAPE, unknown escape sequence read

    By the way, the escape sequence does get transmitted to TPU intact
    as I've demonstrated using EVE's QUOTE command...

    	So to reiterate my questions:

    	    (1) How do I get TPU to accept ESC c as a valid keystroke, and
    	    (2) Why did this change from VMS V4.7.

        Finally, (3) it would be _really_nice_ if I could generate my own
    keywords.  That is, while I can define a keyword variable, such as
    SHFT_TAB_KEY above, I can't get LAST_KEY, etc., to return
    SHFT_TAB_KEY  as the keyname.  Rather, I get "KEY_NAME (90, KEYPAD)".
    Well, I _have_ hacked eve$unknown_key (from EVE$TERMINALS.TPU) to
    return that string, still, it would be nice...

        		Cheers, Ken
--
 Dr. Kenneth H. Fairfield    |  Internet: Fairfield@Slacvx.Slac.Stanford.Edu
 SLAC, P.O.Box 4349, MS 98   |  DECnet:   45537::FAIRFIELD (45537=SLACVX)
 Stanford, CA   94309        |  BITNET    Fairfield@Slacvx
 ----------------------------------------------------------------------------
 These opinions are mine, not SLAC's, Stanford's, nor the DOE's...