wtimeout() and nodelay() do not manipulate the same data structures

[rhaberkorn]

In ncurses you can call

wtimeout(win, 1000);
nodelay(win, TRUE);

And getch() will be nonblocking afterwards. On PDCursesMod it will still be blocking afterwards. I didn't test how it interacts with halfdelay(). Neither did I test whether ncurses applies the 1000ms timeout again after nodelay(win, FALSE).

Workaround: Use wtimeout(win, 0) consistently instead of nodelay(win, TRUE).

[Bill-Gray]

Well, this was trickier than I expected. I still haven't fixed it, but I've at least figured out the following :

The Open Group documentation on curses input processing says (among other things) that nodelay(win, TRUE); sets "No Delay" mode. In this mode, all input functions return immediately if there's no input waiting. (That is to say, in this case, ncurses is right and PDCursesMod is wrong. Haven't checked PDCurses.)

timeout(), however, is specified in a (to me) odd way in the above : it affects situations where part, but not all, of a function key sequence has been entered. I think (but am not certain) that the intended difference between, say, timeout() and halfdelay() is that timeout() sets how long you're willing to wait after the Escape key is hit, in case it's followed by a function key sequence. halfdelay() is intended to say "if the input queue is empty, wait up to this long for input, then return ERR."

Then again, ncurses has the ESCDELAY variable (an extension) to determine how long you're willing to wait after the Escape key is hit.

I'm going to have to do some testing here, see what PDCurses and ncurses actually do, and work from there. I kinda suspect the actual behavior may not mirror that specified at the above link, and that it may prove difficult/dangerous to break with the actual precedent.

[rhaberkorn]

If you want to make your life even harder, consider that there are other historic curses implementations (non-ncurses) alive. NetBSD's curses is very alive and Illumos has libxcurses. 😈

[Bill-Gray]

I've considered NetBSD. For some reason, I thought Illumos wasn't freely available, but it appears I was wrong about that; I might actually give it a try and see what happens. (Downloading the ISO as I write.) But my first comparison will be to ncurses and "upstream" PDCurses (which, I think, should be exactly the same as PDCursesMod. We've changed a lot of other stuff, but I don't recall any relevant changes to input processing.)

[rhaberkorn]

I ported Ilumos' libxcurses to BSD and Linux, just for the fun masochism of it, but haven't published it yet.

[Bill-Gray]

Still puzzling things out here. I used this in_test.c code to check out how all of these input settings work in actual practice. Compile with ncurses and run it, for example, and hit k to call timeout( 1000);, and a spinner starts to rotate one step a second. Hit 'l' to call nodelay( TRUE), and it spins like crazy.

Compile with PDCursesMod or PDCurses and run it, and 'k' does get the desired step-once-a-second behavior. 'l' does nothing. (Which is a long-winded way of saying that I'm seeing the behavior described by @rhaberkorn when opening this issue.)

Llooking at the code, when we compute the milliseconds to wait, the only instance where the delay()/nodelay() setting matters is if halfdelay() is off and timeout() is zero.

Using this test program under ncurses shows no obvious pattern of how the various functions listed interact. I do see that if one calls keypad( stdscr, TRUE); (by hitting 'n'), hitting (say) F3 gets you KEY_F3 (same in PDCurses*). Set it to FALSE (by hitting 'o'), and function keys emit the raw escape sequences instead... which I think is what's supposed to happen. In PDCurses*, hitting 'o' results in function keys being ignored entirely... which, again, is what's supposed to happen. (Except, possibly, on VT, DOS, DOSVGA, framebuffer/DRM, and OS/2 console, where we could return raw escape sequences. I'd rather retain compatibility with other PDCursesMod platforms.)

So far, it looks as if PDCursesMod and PDCurses behave identically. I may mark this as something of possible interest for 'upstream' PDCurses, once I actually know more about what's going on and what "should" be going on.