Re: [AD] key scan codes have changed?

[Evert Glebbeek <eglebbk@xxxxxxxxxx>]

> >>so without knowing what keys should return what.. the question is,
> >>should 4.2b2 readkey() produce different results than 4.1.18's
> >
> > readkey() ?
> >
> > I don't think so.
>
>
> it currently does, therefore "i think" its a bug.

I think we'd already established that.

> if i want to test for alt-c  do i go  if ( readkey() == 0xfc7e )   or do
> i go   if (( (readkey()&0xff) == 7e ) && ( keyshifts & ALT_FLAG ))
> ??????

You'd test if (readkey()==(KEY_C<<8)).
As is in the section of the manual I posted. Twice now.

One note/reminder about changing KEY_* constants: they cannot change
between bugfix releases (ie, 4.2.0 and 4.2.1) because that would break ABI
compatibility. It's perfectly fine for them to change between 4.0 and 4.2
or 4.1.17 and 4.1.18, since the API does not change.

> so now the docs are the official source for what is to be.
> sometimes its the src, and the docs are wrong, sometimes its the docs
> and the source is wrong. sometimes a merry-go-round makes you want to
> vomit... :|

Of course the docs are the reference for what a function should return.
What else would be?
In some cases, functions have undocumented behavior that is promoted to
`official' status by documenting it. Sometimes the docs do not clearly
state what the intention of a function was. But normally, the docs are
definitive for what a function does.

Evert