Re: lynx-dev Link numbering and keypad mode

[Klaus Weide]

On Mon, 15 Feb 1999, Bela Lubkin wrote:
> Kim DeVaughn wrote:
> 
> > Currently we have the following o(ptions) for "keypad mode":
> > 
> >   Keypad mode:  Numbers act as arrows
> >                 Links are numbered
> >                 Links and form fields are numbered
> > 
> > 
> > It seems to me (aka, I would prefer) having these options decoupled,
> > so that we would have something like:
> > 
> >      Keypad mode:  Keys act as numbers
> >                    Keys act as arrows
> > 
> > and
> > 
> >   Link numbering:  Not numbered
> >                    Links are numbered
> >                    Links and form fields are numbered
> 
> I agree with your suggestion.  Let me try to restate it in terms that
> might be more understandable to some of the people who are objecting...
> 
> Basically the idea is to decouple this option, resulting in two new
> options:
> 
>   [1] Keypad acts as:    numbers  OR  arrows

I find this terminology misleading.  It should be:

    [1] Digits act as:     numbers  OR  arrows

Since that's all it is.  The current description "Numbers act as arrows"
IS the better one for this aspect.  Apparently, for you, having a keypad
in a state where it sends digits is so much the normal case that you
identify "keypad" with "digits".  But, for me, that is not the normal case.

>   [2] Link numbers are:  hidden   OR  displayed
> 
> The current behaviors would stay the same.  However, a new combination
> would become available: link numbers are displayed, but keypad acts as
> arrows.

I agree that it would make sense to separate the two functions.

> Note that in keypad-as-arrows mode, there is an escape to get to keypad-
> as-numbers mode: hit "0".  Also, as Ismael Cordeiro points out, the
> keypad is automatically understood as numbers in places where that makes
> sense (anywhere you can enter text -- usually form fields).
> 
> So what [1] really represents is whether you need to prefix a link
> number with a "0" before issuing a follow-link, go-to-link, or go-to-
> page command.  If so, you also get to use those keys as arrows (when not
> prefixed with "0").
> 
> I've presented [2] as a 2- rather than 3-way toggle (currently we have
> hidden vs. displayed(links only) vs. displayed(links and form fields)).
> I think it was a mistake, at the time, to separate the last two.  It was
> an implementation oversight at the time that links-are-numbered was
> first introduced, that form fields were *not* numbered.  It should
> simply have been fixed by making them "first class links", i.e. changing
> the links-are-numbered option to always include form fields.  I'd like
> to see that change now.

I disagree - form fields just aren't first class links.  Real links have
destinations, you can do commands on them that you can't do on form fields,
they make sense when LISTed, and so on.  Personally I don't find the 
numbering of form fields not very useful, especially for textarea lines.

> =============================================================================
> 
> At this point in Lynx's development, I even wonder whether anyone still
> needs "keypad-as-numbers" mode.  

Rephrase it as "numbers-as-numbers", and it seems pretty obvious to me
that this should be the normal case.  I always regarded the "numbers-as-
arrows" as a kludge, for terminals that can't easily send what they are
supposed to send: escape sequences for movement commands.


   Klaus