Re: lynx-dev Lynx 2.8.3.dev4+Slang 1.3.8: arrow keys not working?

[Klaus Weide]

On Fri, 16 Jul 1999, T.E.Dickey wrote:

> > On Fri, 16 Jul 1999, Ismael Cordeiro wrote: 
> > > On Fri, 16 Jul 1999, T.E.Dickey wrote: 
> > >  
> > > > > Hi. I just compiled the latest Lynx devel but I can't get my arrow 
> > > > > keys 
> > > > > to work. 
> > > [snip] 
> > > >  
> > > > mine work (I build 3 copies for my home machine; 1's slang and the 
> > > > arrow 
> > > > keys work in that). 
> > > >  
> > > > dev.4 deprecates some hardcoded escape sequences in favor of what's 
> > > > defined in the terminfo - perhaps your $TERM points to something that 
> > > > has 
> > > > the cursor keys in application mode or vice versa (e.g., \EOA versus 
> > > > \E[A). 
> > >  
> > > I have the same problem on Solaris (terminfo) and FreeBSD (termcap) with 
> > > slang 1.3.7. The cursor keys don't work, only the numeric keypad. 
> >  
> > LYStrings.c: 
> >  
> >         EXTERN_KEY( "\033[A",   "^(ku)", UPARROW,       KEY_UP ), 
> >         EXTERN_KEY( "\033OA",   "^(ku)", UPARROW,       KEY_UP ), 
> >  
> > We could at least have some minimal fallback by changing this to 
> 
> We could (or they could use a terminal description that corresponds to the
> terminal rather than using hardcoded values).  I think it's a bad idea in
> general to encourage this sort of thing (specifically, the tendency to
> hardcode nonstandard behavior into applications and then say that some
> terminal emulators, etc., "don't work").
> 
> -- my point: lynx works properly with the terminal properly configured,
>    adding more hardcoded cases only makes it more likely that we'll get
>    spurious matches on some sequences.

Yes, I agree in principle.

My view is that (thinking only of Unix-like systems)

 - with curses/ncurses, lynx has been traditionally stricter in
   'Doing The Right Thing'.
 - with slang, lynx has traditionally been more lenient (in a way):
   it worked without requiring everything being configured correctly
   - for users in 'sufficiently vtXXX-like' situations.
   (for the price of working not so well in situations where terminal
    differ a lot from vtXXX, I assume.)

So in effect there was a choice: people who want it to do The Right Way
and want it to Work In More Situations pick ncurses; people for whom
'It Works For Me' (in their 'normal' situation) is enough can pick slang.

Adding this patch, without any fallback for those who can't get their
TERM description right, suddenly increases the requirements for using
lynx-with-slang.  We are not talking about adding more encouragement
for Bad Things, but about taking away something that "worked" (for
many people at least).

Actually, with the code as it is now, lynx-with-slang has become *more*
strict than lynx-with-ncurses: the latter still uses all the ancient
hardcoded sequences in LYgetch_for, which are not in the code path for
slang.

In practice, I haven't seen an indication that 'spurious matches' have
been a problem in reality, so far.  They *could* become one if more and
more hardcoded cases were added, but no one is really suggesting that.

> 
> >         EXTERN_KEY( "\033[A",   "^(ku)", UPARROW,       KEY_UP ), 
> >         EXTERN_KEY( "\033OA",   "\033OA", UPARROW,       KEY_UP ), 
> >  
> > the duplication of "^(ku)" seems pointless.  This change wouldn't add 
> 
> That chunk of code is really for VMS.  (apparently the termcap support in
> slang isn't portable to non-Unix platforms).  The VMS support is really
> the only valid justification for the table.

But the table seems to be used even with ncurses.  (Before this change at
least; I didn't verify whether dev.4 changed that)


   Klaus