+</PRE><H3><a name="h3-timeout_wtimeout">timeout/wtimeout</a></H3><PRE>
+ The <B>timeout</B> and <B>wtimeout</B> routines set blocking or non-blocking read for
+ a given window. If <I>delay</I> is negative, blocking read is used (i.e.,
+ waits indefinitely for input). If <I>delay</I> is zero, then non-blocking
+ read is used (i.e., read returns <B>ERR</B> if no input is waiting). If <I>delay</I>
+ is positive, then read blocks for <I>delay</I> milliseconds, and returns <B>ERR</B>
+ if there is still no input. Hence, these routines provide the same
+ functionality as <B>nodelay</B>, plus the additional capability of being able
+ to block for only <I>delay</I> milliseconds (where <I>delay</I> is positive).
+
+
+</PRE><H3><a name="h3-typeahead">typeahead</a></H3><PRE>
+ The <B>curses</B> library does "line-breakout optimization" by looking for ty-
+ peahead periodically while updating the screen. If input is found, and
+ it is coming from a tty, the current update is postponed until <B>re-</B>
+ <B><A HREF="refresh.3X.html">fresh(3X)</A></B> or <B>doupdate</B> is called again. This allows faster response to
+ commands typed in advance. Normally, the input FILE pointer passed to
+ <B>newterm</B>, or <B>stdin</B> in the case that <B>initscr</B> was used, will be used to do
+ this typeahead checking. The <B>typeahead</B> routine specifies that the file
+ descriptor <I>fd</I> is to be used to check for typeahead instead. If <I>fd</I> is
+ -1, then no typeahead checking is done.
+
+
+</PRE><H2><a name="h2-RETURN-VALUE">RETURN VALUE</a></H2><PRE>
+ All routines that return an integer return <B>ERR</B> upon failure and <B>OK</B>
+ (SVr4 specifies only "an integer value other than <B>ERR</B>") upon successful
+ completion, unless otherwise noted in the preceding routine descrip-
+ tions.
+
+ X/Open does not define any error conditions. In this implementation,
+ functions with a window parameter will return an error if it is null.
+ Any function will also return an error if the terminal was not initial-
+ ized. Also,
+
+ <B>halfdelay</B>
+ returns an error if its parameter is outside the range
+ 1..255.
+
+
+</PRE><H2><a name="h2-PORTABILITY">PORTABILITY</a></H2><PRE>
+ These functions are described in the XSI Curses standard, Issue 4.
+
+ The ncurses library obeys the XPG4 standard and the historical practice
+ of the AT&T curses implementations, in that the echo bit is cleared
+ when curses initializes the terminal state. BSD curses differed from
+ this slightly; it left the echo bit on at initialization, but the BSD
+ <B>raw</B> call turned it off as a side-effect. For best portability, set
+ <B>echo</B> or <B>noecho</B> explicitly just after initialization, even if your pro-
+ gram remains in cooked mode.
+
+ The XSI Curses standard is ambiguous on the question of whether <B>raw</B>
+ should disable the CRLF translations controlled by <B>nl</B> and <B>nonl</B>. BSD
+ curses did turn off these translations; AT&T curses (at least as late
+ as SVr1) did not. We chose to do so, on the theory that a programmer
+ requesting raw input wants a clean (ideally 8-bit clean) connection
+ that the operating system will not alter.
+
+ When <B>keypad</B> is first enabled, ncurses loads the key-definitions for the
+ current terminal description. If the terminal description includes ex-
+ tended string capabilities, e.g., from using the <B>-x</B> option of <B>tic</B>, then
+ ncurses also defines keys for the capabilities whose names begin with
+ "k". The corresponding keycodes are generated and (depending on previ-
+ ous loads of terminal descriptions) may differ from one execution of a
+ program to the next. The generated keycodes are recognized by the <B>key-</B>
+ <B>name</B> function (which will then return a name beginning with "k" denot-
+ ing the terminfo capability name rather than "K", used for curses key-
+ names). On the other hand, an application can use <B>define_key</B> to estab-
+ lish a specific keycode for a given string. This makes it possible for
+ an application to check for an extended capability's presence with
+ <B>tigetstr</B>, and reassign the keycode to match its own needs.
+
+ Low-level applications can use <B>tigetstr</B> to obtain the definition of any
+ particular string capability. Higher-level applications which use the
+ curses <B>wgetch</B> and similar functions to return keycodes rely upon the
+ order in which the strings are loaded. If more than one key definition
+ has the same string value, then <B>wgetch</B> can return only one keycode.
+ Most curses implementations (including ncurses) load key definitions in
+ the order defined by the array of string capability names. The last
+ key to be loaded determines the keycode which will be returned. In
+ ncurses, you may also have extended capabilities interpreted as key
+ definitions. These are loaded after the predefined keys, and if a ca-
+ pability's value is the same as a previously-loaded key definition, the
+ later definition is the one used.
+
+
+</PRE><H2><a name="h2-NOTES">NOTES</a></H2><PRE>
+ Note that <B>echo</B>, <B>noecho</B>, <B>halfdelay</B>, <B>intrflush</B>, <B>meta</B>, <B>nl</B>, <B>nonl</B>, <B>nodelay</B>,
+ <B>notimeout</B>, <B>noqiflush</B>, <B>qiflush</B>, <B>timeout</B>, and <B>wtimeout</B> may be macros.
+
+ The <B>noraw</B> and <B>nocbreak</B> calls follow historical practice in that they
+ attempt to restore to normal ("cooked") mode from raw and cbreak modes
+ respectively. Mixing raw/noraw and cbreak/nocbreak calls leads to tty
+ driver control states that are hard to predict or understand; it is not