Re: lynx-dev fast forward and back commands (was: next/prev...)

[Klaus Weide]

On Sat, 27 Feb 1999, Laura Eaves wrote:

> Ok, I looked at CHANGES and lynx.cfg and noticed 
> 
> #KEYMAP:0x10F:FASTBACKW_LINK  # Move always to previous link or text area
> #KEYMAP:^I:FASTFORW_LINK      # Move always to next link or text area
> 
> First, I got <tab> to work but not 0x10F.  Since I don't know what key (if 
> any)
> produces this code, I tried entering it using alt271, but it still didn't 
> work.
> Perhaps you could point me to the appropriate key sequence.

CHANGES says:

* new lynxkeycode BACKTAB_KEY with value 0x10F.  DO_NOTHING is and shall remain
  0x10E, as documented in lynx.cfg.  Moved MOUSE_KEY out of the way - does it
  need to be in the tables at all?  BACKTAB_KEY will be recognized if the
  (n)curses keypad() input handling returns KEY_BTAB, which happens if the
  terminal description has the right kB or kcbt capability string and the
  terminal actually generates that string (often "^[[Z", generated for
  shift+tab).  May also work with lynx-keymaps mechanism.  Not tested with
  slang, maybe this has to be added to some more of the various tables in
  LYStrings.c - KW

See also samples/lynx-keymaps.

I don't know what more I can add to that.  Except that, if you are using
slang, you could investigate the "maybe this has to be added to some
more of the various tables" bit.

Of course you can also just forget about (lynxkeycode) BACKTAB_KEY and
just map some other key, for example (lynxkeycode) UPARROW aka 0x100,
to (lynxactioncode) LYK_FASTBACKW_LINK.

> Also, it would be useful to distinguish between what 1+g and 1-g currently do
> from what your commands do.  My command is different in that
> it skips to the next/previous *numbered* link.
> This means that if form fields are not numbered, 1+g will skip
> all form fields and link-less pages to get to the next numbered link.
> 
> I can see where both commands are useful.
> I wondered if 1+g should be changed to do something like
> your command -- but since the numeric commands 123 and 123g
> deal with link numbers I concluded the current behavior for
> 1+g is more appropriate.  (The user expects to go to a numbered entity.)
> 
> Comments?

Yes they are different, and it seems consistent that your addition only
goes to numbered links or fields, as the other NNN commands do.

I don't personally see a need for your addition (now), but I have nothing
against it.

    Klaus