Re: pkg/41423: CenterIM unusable: ignores several keys (like enter)

[Julian Coleman <jdc%coris.org.uk@localhost>]

The following reply was made to PR pkg/41423; it has been noted by GNATS.

From: Julian Coleman <jdc%coris.org.uk@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: pkg/41423: CenterIM unusable: ignores several keys (like enter)
Date: Fri, 22 May 2009 13:26:08 +0100

 Hi,
 
 > >                                   When it starts up, the screen looks OK
 > >  apart from any highlighted items are white on white (title, current
 > >  selection).
  
 > That's an interesting new behavior I haven't seen, yet.
 > libcurses, I guess?
 
 Yes.  I am doing all my tests with NetBSD's libcurses.
 
 The white on white behaviour is a centerim bug - it sets the highlighted
 items to be white foreground and default (i.e. whatever the terminal is set
 to) background colours.  As I use white background, I get white on white ;-)
 
 > Well, with this line, CenterIM was at least displaying everything the way
 > it was meant (on my machine, that is).
 
 As I mentioned, this looks like a refresh() difference between NetBSD curses
 and ncurses.  I think it's to do with interactions between different curses
 windows (i.e. the background and the dialog box), where the specification is
 not clear on behaviour.
 
 > I just downloaded, compiled and installed CenterIM 4.22.7 from
 > centerim.org . The behavior is just the same as with the pkgsrc-version
 > AND the INCOMPAT_CURSES-line, meaning everything that works is displayed
 > properly, but the keys are not responding as one would expect, in the very
 > same way as before.
 
 Thanks for checking.  At least the versions of CenterIM are consistent.
 
 I have narrowed down the problem further.  For some reason, when we call
 getchar() from the curses library (src/lib/libcurses/getch.c:602), it
 returns -1 for the second character in an escape sequence (e.g. left arrow
 is the three characters <esc> O D when using an xterm).  This causes
 the parsing in "assembling a key sequence" state to abort.  (The other
 characters in the escape sequence are read after the extra -1.)  Also, as I
 mentioned previously, if I slow everything down by using a curses library
 with enough debug enabled, we read the key sequences for the arrow keys
 without a problem.
 
 I will see if I can spot why getchar() is returning -1.
 
 Thanks,
 
 J
 
 -- 
   My other computer also runs NetBSD    /        Sailing at Newbiggin
         http://www.netbsd.org/        /   http://www.newbigginsailingclub.org/