lynx-dev Re: next/prev link

[Kim DeVaughn]

On Mon, Feb 08, 1999, Bela Lubkin (address@hidden) said:
|
| > Are you aware that <TAB> already does something like this?  Except that,
| > like the normal NEXT_LINK, it does't go to the next screen unless the last
| > "link" (or textarea line) on the screen is selected.
|
| Yes, that's why I proposed <TAB> for the new function.  Basically I'd
| like it to do the same as the current <TAB>, except for two details:
| skip pages which have no links, and visit textareas only once, rather
| than once for each line of the area.
|
| Hmmm.  Ok, I *remembered* that <TAB> visited each line of a textarea,
| but apparently that memory is false.  Maybe it used to work that way.

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.

Not sure exactly what it does on the boundary condition cases (eg, the
bottom line on the screen also being the last line of the TEXTAREA, 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 ...?


| > 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.

Agreed.

/kim