Fix: Unshifted keypad ENTER is not treated as keyboard ENTER.

This problem arises when a (typically GUI) user expects that the
ENTER key on the numeric keypad should work the same as the ENTER key
on the keyboard.  This is a reasonable expectation, but it doesn't.

How the keypad ENTER key is reported to the application depends on
the termcap '@8' or terminfo 'kent' capability.  Using 'linux' as the
$TERM setting (as consoles usually do) results in the default 0x0a
(newline) being reported for both ENTER keypresses, while 'xterm' (and
other GUI settings) mostly return newline for keyboard ENTER but 0x157
(represented by ncurses as KEY_ENTER) for keypad ENTER.

(The shifted keypad ENTER does return a newline in all cases.)

Of the $TERM settings tested, this commit fixes the problem for all
but 'xterm-color' which returns 0xcf.  However, 'xterm-color' may
have been superceded by 'xterm-16color' and 'xterm-256color' anyway.

git-svn-id: svn://svn.daper.net/moc/trunk@2999 910807d9-36e0-0310-a014-e9ea483e2ba4

interface_elements.c

@@ -3896,6 +3896,10 @@ void iface_get_key (struct iface_key *k)
 	if (ch == (wint_t)ERR)
 		interface_fatal ("wgetch() failed!");
 
+	/* Handle keypad ENTER as newline. */
+	if (ch == KEY_ENTER)
+		ch = '\n';
+
 	if (ch < 32 && ch != '\n' && ch != '\t' && ch != KEY_ESCAPE) {
 		/* Unprintable, generally control sequences */
 		k->type = IFACE_KEY_FUNCTION;