[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev Re: next/prev link
From: |
Klaus Weide |
Subject: |
Re: lynx-dev Re: next/prev link |
Date: |
Tue, 9 Feb 1999 06:58:26 -0600 (CST) |
On Tue, 9 Feb 1999, Kim DeVaughn wrote:
>
> What you may be remembering, is that if you're in a TEXTAREA that crosses
> the bottom of the screen, when you hit TAB, it takes you to the bottom of
> that screen. When you hit TAB again, it takes you to the top line of
> the next screenfull (you're still in the TEXTAREA). And then another
> TAB will take you to the 1st anchor following the TEXTAREA ... unless of
> course, the TEXTAREA flows into yet a 3rd screen. Etc.
> [ ... ]
>
> I've gotten quite used to this behavior, while developing the external
> TEXTAREA edit function, but I could certainly retrain myself if that
> behavior were to change to bypass all the rest of the TEXTAREA you're in.
>
> Seems a bit of a shame though, since the coding to make it perform in
> the current way, is not insignificant, I would bet.
>
> Do I smell YAO ...?
O = Option?
> | > I wouldn't mind if this different behavior of <TAB> were made explicit,
> | > by giving it a different function that appears as such on the 'K' page.
> | > It seems to make sense to have that function behave as you describe.
> |
> | Yes, indeed. The #ifdef FASTTAB code which explicitly tests " c=='\t' "
> | is wrongly hard coded. Make it go through the usual command binding
> | paths.
Compromise:
- Make NEW_AND_IMPROVED_NEXT_LINK implementation
- make it default mapping for <TAB>
- but keep the #ifdef FASTTAB " c=='\t' " test for bw compatibility
then Kim maps <TAB> to (old) NEXT_LINK and is happy, and we don't need
YAO.
Klaus