> >I think the immediate workaround is not to use curses keypad() function
> >(undef HAVE_CURSES_KEYPAD).  Nvi version of the function is different
> >from that of curses.
> >
> >But, hmm...,
> >I think the traditional curses had an exported function "tstp()",
> >which does suspend and all the troublesome things about it
> >in place of the userland programmer.
> >
> >What is the correct way to suspend a process with modern curses?
> >__stop_signal_handler() does it, but it doesn't seem exported....
> 
> please note that it's not *just* being suspended that messes up vi.
> if i suspend it and then resume, i'm fine.  it's only if the other
> thing that i do in between also involves the "alternate" screen, which
> for me is the difference between 'printf "\e[?47h"' and 'printf
> "\e[?47l"' (in an xterm).  i dunno what that's really called.  maybe
> it's actually a bug in curses...

The cause is that we don't send the escape sequences for keypad on/keypad off
when the keypad() function is called.  This isn't clear in the documentation
but is what the Solaris implementation does.  It seems to me that this can be
suboptimal in some cases, but in order to be compatible, I will change our
curses to do this.

The problem occurs because vi installs its own signal handler which bypasses
our curses' handler (which would send the correct escape sequences).  Thus,
keypad mode is left set when vi suspends and is then unset when a curses or
termcap using program is run (e.g. vi or man).  When you resume vi, the
keypad is now unset.

Fix on its way (just need to do a few more tests) ...

J

-- 
                    My other computer also runs NetBSD
                          http://www.netbsd.org/