>
> Hello Dan,
>
>   DLB> I think the thread is actually talking about grey pad
>      > delete, the delete in the pad between main keyboard
>      > area and number pad in the pc/xt keyboard, and pc/at
>      > keyboard
>
> On my PC keyboard, all my keys are white. I probably have an
> old IBM PS/2 keyboard somewhere with grey keys though.  I
> have a key marked '<-' above the main Return/Enter key which
> I expect sends \010.  I have a Delete key (which I would
> expect to send \177) on a small 3x2 cluster above th
> inverted-T cursor keys.  On the numeric pad I have a Del key
> which should send '.' when Num Lock is on and either \177 or
> perhaps Esc O n if it's pretending to be a DEC keyboard

I had actually completely forgotten that it does that on PC/dos
as well, being so long since I programmed on dos.  My perspective may 
be warped
somewhat, in that I see curses as a way to do implement text-mode 
programs, and
I see keyboard esc sequences as a means to an end, a way provide 
similiar functionality,
as scan codes, but better, since the app isn't tied to the keyboard.


> od doesn't seem all that clear for me (perhaps something is
> interpreting backspace before od sees it).  I would be
> interested in seeing what codes were generated by each of
> these three keys.
>
> I'm running NetBSD/i386-1.6.1 on the only NetBSD machine
> here that has a display and keyboard attached.
>
>   DLB> I suppose I will retract any comment about
>      > inconsistency , since I don't want to be more
>      > consistent with vt220.
>
> But if that's what wscons emulates...?
That it's pc/i386 behavior is actually more persuasive to me, than any 
vt220 argument.
Since the keyboard is vastly different from a vt220, there is no way to 
do 100% emulation and I would not want to, I like shift-comma to send < 
for instance -- I don't really want my keyboard to pretend to be a 
vt220, appropriate some esc sequences here and there, yes, as there's 
there no need to re-invent the wheel, but I don't really care what is 
emulated,
as long as it provides sufficient capability to they layers above it.

Regarding my complaint about consistency:
Consider that grey home sends the same as keypad home, grey pgup, sends 
the same as keypad pgup,  grey left arrow sends sames as keypad 
arrow... One could claim that
the grey keys map the same as the keypad keys, except for del, grey del 
is doing ^?, while
keypad del is sending ESC [[3~.  It would be clean and consistent if it 
also does the same,  I'm not going to lose anything since I have 2 ways 
to get ^? already, rubout and CTRL-?.  So, my complaint was that it 
wasn't consistent to itself, looking at from the
point of few that wscons providing a layer that termcap/curses can use 
and exploit.
I had actually forgotten that pc/dos does ^? , but on dos. I'd likely 
be looking
at scan codes anyway if I was trying to do anything with arrow keys and 
the like.

As a terminal, whether the vt220 itself or wscons,  I think if a delete 
key is on or adjacent to the main pad then sending ^? makes sense, as 
it is consistent with keys like
TAB, RETURN , LINEFEED, and BACKSPACE ( ^I, ^M, ^J, ^H ), it like 
they're there as a convenience, for 1 finger press operation of their 
ASCII control equivalents.   Once off the main keypad, with its 
neighbors sending esc codes, well it's subjective, but it feels like 
bad design to me, and it doesn't really give the user  anything useful, 
might as well be an extra tab key.

At any rate, I find in termcap(5) that attribute kD describes what is 
"Sent by delete-character key".  Digging through  
/usr/share/misc/termcap I find that the wsvt25 entry
itself doesn't define kD itself, but includes vt220 , in vt220 kD is 
\E[3~ .
With keypad(TRUE) , curses' getch() etc, will return a KEY_DC.  Again, 
it my opinion
but from curses(3) viewpoint, sending ^? for the grey delete key, and 
kD for the other
is a design quirk, and I care more about making thing work smoothly 
with curses, rather than strict adherence to the vt220.   And these 
days I can less what DOS does.