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/