Subject: Re: bin/10116: vi somewhat easily confused by suspension
To: None <gnats-bugs@gnats.netbsd.org, tech-userlevel@netbsd.org>
From: Julian Coleman <J.D.Coleman@newcastle.ac.uk>
List: tech-userlevel
Date: 05/19/2000 12:09:25
> I agree they are corner cases, but
> I can't conclude that no program interprets keypad char by its own.
> 
> If the "disable keypad" sequence is sent by keypad(win, FALSE),
> such a program can't know the sequence sent by a keypad key.

That's true.  However, that is the way the specification is written - if you
call wgetch(win) after keypad(win, FALSE), you will not get the application
keypad sequence; if you call wgetch(win) after keypad(win, TRUE), you will
get the keycode, not the sequence.  I admit that this doesn't happen under
Solaris (all SysV curses?) because it doesn't comform to the specification.
However, ncurses does what our curses now does, so such a program won't work
there either.

> Nvi depends on the behavior of old and obsolete BSD curses.
> Now we have new curses.  Why don't we fix nvi?
> 
> How does it work if just undef HAVE_BSD_CURSES?
> (I havn't tried it, yet.)

On inspection, it calls endwin(), doesn't bother with some tcgetattr() and
tcsetattr() calls and doesn't send the ti/te sequences.  We now support
restarting after endwin() and it appears to work OK without HAVE_BSD_CURSES
defined (just tried it).  So, we can take out the sending of the sequences in
keypad() if we undefine HAVE_BSD_CURSES in vi.  Still won't help any curses
program to interpret the keypad sequences itself but it will get rid of the
multiple sequences sent corner case.  Thoughts?

I wonder if vi should use reset_shell_mode() and reset_prog_mode() instead ...
hmm, we should probably send the relevant sequences here too (Solaris curses
doesn't but ncurses does) - I'll fix that.

J

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