Re: nap and ncurses advice sought

[Mike Castle]

On Thu, Dec 13, 2001 at 07:20:32PM -0500, Thomas E. Dickey wrote:
> On Thu, 13 Dec 2001, Mike Castle wrote:
> 
> > So, is sending the smkx the responsibility of the application or ncurses?
> 
> I don't recall that lynx handles SIGTSTP, but do know that ncurses does.
> So it's ncurses' responsibility.

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.

Of course, keypad() is called with a particular window, not stdscr.

It seems like there is no global way of tracking the state of keypad mode.

Also, this makes me wonder about another issue.

If keypad mode gets turned on for one window, but not another, shouldn't it
be that keypad mode is NOT on for the second window?

The following test program seems to indicate that.

Running under xterm, with no parameters, and hit up-arrow, and it shows 
27 91 65.  Run it with any parameter, and it shows 27 79 65.

/* My first curses program.  Don't laugh. */
#include <ncurses.h>

int main(int argc, char * argv[])
{
  WINDOW *w1, *w2;

  initscr();

  w1 = newwin(10, 10, 0, 0);
  w2 = newwin(10, 10, 0, 12);

  if (argc>1) keypad(w1, TRUE);
  waddstr(w1, "Win 1\n");
  wprintw(w2, "Win %d\n", 2);
  wrefresh(w1);
  wrefresh(w2);

  while(1) {
    int ch = wgetch(w2);
    if (ch == 'q') break;
    wprintw(w1, "%d\n", ch);
    wrefresh(w1);
  }
  endwin();
}

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).

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.

Anyway, it seems to me that, since keypad takes a window parameter, it
should be settable on a per window basis.

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.

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?
mrc

PS:  tty_update.c has a comment at the top about lib_doupdate.c.  Led me
astray once or twice.
-- 
     Mike Castle      address@hidden      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc