🚀 go-pugleaf

>I guess I do not understand why the keyboard of a Sun386 behaves
>differently than on a Sun 2 or 3, but it does.  When in suntools
>on a Sun2 running OS 3.4, if you type one of the right keypad keys,
>an escape sequence is printed on the screen.  In emacs, this sequence
>can be redefined as an emacs command using the global-set-key in a
>.emacs file.  This absolutely does not work on the Sun386 running OS
>4.0 and sunview windows.  Typing a function key does not seem to
>generate a unique escape sequence, nor is this sequence even perceived
>by emacs when it is running.

I.e., when you run, say, a "shelltool" (NOT a "cmdtool"), and you type
one of the right-hand keys, it doesn't send an escape sequence?

For instance, the key labelled R1 should, on all Suns that have such a
key - this includes Suns with the Sun-2 keyboard, Sun-3s and Sun-4s with
the Type 3 (formerly known as Sun-3) keyboard, and Sun386is with the
Type 4 keyboard) send '<ESC>[208z'.  If this does not work on the
Sun386i, there's a bug somewhere.  The Type 4 keyboard is supposed to
act as a superset of the Type 3 keyboard. 

Note, however, that when running SunView, the "keyboard driver" does not
generate escape sequences; instead, it generates "function key" events. 
If the program in question hasn't explicitly requested them (by
monkeying somehow with the input event mask - I'm not familiar with the
details here), the SunView kernel event handling code turns them into a
sequence of events corresponding to the characters of the escape
sequence in question.  I don't know whether GNU EMACS requests "function
key" events, or whether it just gets escape sequences.

There may have been a change between SunOS 3.x's SunView and SunOS 4.0's
Sunview that affects this, or between non-386i SunOS's SunView and 386i
SunOS's SunView, so it is not inconceivable that something inside EMACS
needs to be changed.  This is unlikely, however; it may just be that
there is a bug in the 386i's SunView code.