Re: lynx-dev Keys, an attempt to understand

[Doug Kaufman]

On Tue, 9 Feb 1999, Klaus Weide wrote:

> ...
> Then comes the recently discovered (for me :) ) customizable "lynx-keymaps"
> file.  (Again a reminder that this is not historical sequence.)  This
> provides yet another way to map byte squences to lynxkeycodes, either
> directly or indirectly via KEY_* curseskeycodes or some symbolic names.
> It is still another way of 1. -> 2. mapping.
> 
> Then comes Lynx for DOS, in various flavours.  Suddenly input isn't a
> sequence of bytes, but some extended codes gotten somehow from the systems.
> Codes for keys beyond single bytes are provided in some form, assigned by
> the libraries used in the various flavours in incompatible ways (between
> each other as well as anything already in the Lynx code).
> 
> The logical way to deal with this would have been to treat these new kinds
> of codes as yet more variations on the 1a. theme: Something not assigned by
> us, which has to be translated to how we represent keys.  But this is not
> what happened.  Instead, the space of new codes was identified with the
> space of lynxkeycodes.  This breaks several of the properties of
> lynxkeycodes, essential and otherwise, and ever since there was a mess...

I think this analysis is basically correct. The DOS key
representations are analogous to the curses keymaps. If I remember,
the curses keymaps are translated to lynxkeycodes by nonalterable
(by the user) tables in the lynx code. I don't think that the space
of new codes was identified with the space of lynxkeycodes. Rather,
I would say that the space of lynxkeycodes was extended, with all
the new codes mapped to '0'. The DOS key representations can then be
mapped 1:1 to the corresponding lynxkeycodes, which can, in turn, be
assigned to a lynxactioncode via the KEYMAP code in lynx.cfg. It would
be cleaner if all the extended lynxkeycodes were left assigned to
'0', but I thought it was necessary to have the basic key functions
that the novice DOS user would expect as the default. The last patch
I submitted would leave almost all the mappings at '0' unless this is
DOS or WINDOWS.

Wayne initally had some of the DOS keys hardcoded analogous to the
curses representations in his DOSKEYHACK code, but users couldn't
remap any of these keys.

I don't understand when you say that extending the lynxkeycode space
broke properties. Can you try to explain what broke and how? Thanks.
                                  Doug
__
Doug Kaufman
Internet: address@hidden (preferred)
          address@hidden