How to get a function key in BSD curses

[Leo de Wit]

In article <520 at gagme.chi.il.us> greg at gagme.chi.il.us (Gregory Gulik) writes:
|In article <502 at seer.UUCP> bll at seer.UUCP (Brad Lanam) writes:
|>
|>    Is there some easy way to get a function key using Berkeley curses?
|>I don't have access to the documentation, and the O'Reilly "curses" book
|>doesn't mention anything about the special keys.
|
|Use the keypad(win,bf) function.
|
|For example, I always do:	keypad(stdscr,1);
|to turn on keypad mode.
|
|Then, you can use the getch() function to read the keys in.  Look
|at your system's curses.h file for the key definitions.  Mine has
|a lot of comments explaining what they are.
|
|Oh, you may want to call cbreak() to get into one-key-at-a-time
|mode.

Sorry to correct you Greg, but as far as I know BSD curses (which is
where the question was about) doesn't have keypad(); it is a AT&T-ism.

So in the Berkeley variant you will have to roll your own; this is not too
hard, and I'll try to sketch it out globally:

a) For each terminal capability that represents a function key - globally
speaking the k... capabilities - fetch that capability. See the manual page
for termcap(3) (functions like tgetent, tgetstr etc.).

b) You will have to do some translation of possibile capabilities to
keycodes returned, e.g. if kup (cursor up) was pressed, you want to
return KEY_UP (which will be a unique code in your header file, that
you include wherever you include curses.h; following the AT&T example
you could reserve codes above 0x100 for function keys, so that the
lower codes can be used for ordinary ASCII characters). This could
be implemented by an array of structs containing a capability name
and a keycode.

c) Instead of using (w)getch, create your own function that calls
(w)getch to get characters. You will probably want to set cbreak() and
noecho(). Now, as long as characters recieved through (w)getch form
a prefix to one or more function key sequences, store them in a buffer.
As soon as you get
    1) exactly one match   -->  return the corresponding keycode
    2) no more matches     -->  return each character in the buffer separately
                               (using a static buffer, and index).
    3) time out            -->  like 2).

3) (setting up an alarm & signal) is needed for instance if you want to
process a single escape key; you must be able to tell apart a single
esc sequence, e.g. "\33[D", from the three separate characters (though
I agree with whoever says that using both escape sequences and an esc
key is asking for trouble; you can't do it consistently).

Cheers,
         Leo.