Re: nap and ncurses advice sought

[Thomas Dickey]

On Fri, Dec 14, 2001 at 09:36:53AM -0800, Mike Castle wrote:
> In lib_tstp.c, after the SIGCONT is received, doupdate() is called where
> SP->_endwin is TRUE, so reset_prog_mode() is called.
> 
> However, reset_prog_mode() determines that stdscr->_use_keypad is false, so
> _nc_keypad(TRUE) is not called.

right (from your report I assumed that was what was happening).  odd that
no one noticed it before (I don't use suspend much myself).
 
> Of course, keypad() is called with a particular window, not stdscr.
...
> What's worse, if I do somethine like keypad(w1, TRUE); keypad(w2, FALSE);
> w1 will NEVER see correct application mode operation.
> 
> For nap (and possibly lynx, didn't test there yet), simply adding
> keypad(stdscr, TRUE) right after the other keypad call _seems_ to solve the
> problem of application mode being reenabled after a c-Z/fg operation. (For
> nap, this change will probably always be necessary).

it does rely on a side-effect though...
 
> However, is this a bug in ncurses or is this working as designed?  And how
> does it compare to SysV?  Hmmm... is Intel Solaris still free for personal
> use?  Might be worth it to throw it on an old box for such tests.

I have Solaris 7 (along with other stuff) on my older box.  But I usually test
Solaris curses stuff on my ISP account since the Solaris 7 isn't networked
(doesn't recognize the card).
 
> Anyway, it seems to me that, since keypad takes a window parameter, it
> should be settable on a per window basis.

it should - ncurses only has one input queue, and it's either in keypad
mode, or not.  I don't recall that the keypad function has been checked
to see if Solaris pays attention to the window, but there are a few
other functions that it is the case the Solaris ignores that param.

(but it's worth checking, if only to find that I have more work to do ;-)
 
> Adding an extra state to struct screen, like _keypad_active, might be
> warranted.  I suppose SP->_stdscr->_use_keypad, or similar could fit the
> bill here.  And have _nc_keypad() update it as appropriate.

right (the input queue is in SP, anyway)
 
> Then, on input, if win->_use_keypad and SP->_keypad_active don't match,
> send the appropriate sequence.
> 
> And then reset_prog_mode() would be modified to check SP->_keypad_active 
> RATHER than stdscr->_use_keypad.
> 
> Actually, I guess the endwin() call in tstp would reset that wouldn't it?
> So that state would have to be saved restored.
> 
> Does that seem reasonable?

something like that (I'll have to sort through it)

> mrc
> 
> PS:  tty_update.c has a comment at the top about lib_doupdate.c.  Led me
> astray once or twice.

( well, yes - occasionally I look at the comments and fix those, too ;-)

-- 
Thomas E. Dickey <address@hidden>
http://invisible-island.net
ftp://invisible-island.net