Re: Linux port trouble

Brent Ross wrote:
> In article <[EMAIL PROTECTED]>,
> copx <[EMAIL PROTECTED]> wrote:

[snip description of ESC delay problem with curses]

> // Is there a way to turn off this behaviour?
>
> You could set ESCDELAY to zero, but that's a bit crude.
> Its typically more suitable and elegant to use nodelay()
> or timeout().  Using these, or even raw mode, can give you low
> level access that should allow for a better solution (or at
> least a more controllable one).  The curs_inopts man page is
> probably of interest to you.

I tried nodelay(), timeout() and raw() with ncurses, which seems to be 
the standard implementation of curses on linux.  Unfortunately they all 
don't change the ESC delay.  Even in "non-blocking" nodelay-mode ncurses 
will block and wait after it reads ESC.

I searched on and found the function notimeout(), whose purpose, 
according to the man pages, is to turn off the delay for interpreting 
escape sequences.  I tried it, and it did absolutely nothing.

Setting ESCDELAY actually worked.  It's not overly portable though, 
since with PDCurses on Windows I get "ESCDELAY undeclared" errors. And 
of course it might cause problems when playing over telnet or ssh.

There's another way to turn off the ESC delay in ncurses: If you set 
keypad() to FALSE, ncurses won't wait after it reads ESC.  The downside 
is that it won't interpret any escape sequences then, so you get the raw 
escape sequences when you press e.g. one of the arrow keys.

Alas, the real problem lies deeper: Curses or not, with the ANSI escape 
sequences you can never know if the ESC char you read is the beginning 
of an escape sequence or not.  Since the keycodes are translated into 
escape sequences before curses even sees them, the only way I see around 
this problem would be to read the input from the keyboard directly. 
That's possible, but then you probably lose the ability to play your 
game over telnet or ssh.