Re: Bugs when porting ncurses to a new platform

Hi,

I've done a few more tests. If I assign single characters to ku/kd/kr/kl, l=
ike
"ku=3DA", it works as expected (when I press A I get a KEY_UP event). It's =
just
multi-character strings that fail. However, I have noticed that if I make i=
t
"ku=3DAA" it will hang slightly after I press the first A (and then I just
receive an A key press event instead of KEY_UP because it hasn't seen a sec=
ond
A). So I think that there may be some issue with some wait loop in ncurses.=
..

Antonio

On Saturday, July 4th, 2026 at 11:39 AM, Antonio Ni=C3=B1o D=C3=ADaz <anton=
[email protected]> wrote:

> Hi!
>=20
> I've got this almost working, all I need to do right now is to inject spe=
cial
> key presses into the stdin buffer and let ncurses give me the right KEY_*
> defines with getch(). Well, I also want to support mouse events, but that=
's
> probably the same thing (adding more escape sequences to stdin).
>=20
> I have added the following to my termcaps:
>=20
>     :ku=3D\E[A:\
>     :kd=3D\E[B:\
>     :kr=3D\E[C:\
>     :kl=3D\E[D:\
>=20
> So that calling `has_key(KEY_UP)` and such returns 1.
>=20
> Also, I've called the following from my test code:
>=20
>     keypad(stdscr, TRUE);
>     cbreak();
>     timeout(0);
>=20
> Then, from my own keyboard driver, whenever I detect I've pressed "up" I =
add
> the characters '\x1B', '[' and 'A' to the stdin buffer the same way I add=
 any
> other regular character (like 'g', '!', etc).
>=20
> getch() works with regular characters (and with '\n') but it returns me
> individual characters of the escape sequence instead of KEY_UP.
>=20
> I've also noticed that if there is more than one character in my stdin bu=
ffer
> ncurses won't behave as expected, so this may be a bug in my keyboard/std=
in
> driver. I'm just trying to rule out ncurses configuration issues.
>=20
> Am I missing something?
>=20
> Thanks,
> Antonio