Re: lynx-dev Keys, an attempt to understand

[Klaus Weide]

On Tue, 9 Feb 1999, Doug Kaufman wrote:
> 
> 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. 

Ok, but if the DOS key codes really are mapped strictly 1:1 to the
extended region, that is functionally the same as saying that the
spaces are identified (or at least what I meant by that).  They are
used as indices in the same 2. -> 3. tables.

But I see now that things are even more complicated that I thought.
I hadn't paid attention to the "switch(c) {" stuff in LYgetch_for.
(I think I said I was taking a step back...)  With that taken into
account, you don't really have a 1:1 mapping for all keys, but a
mixture of specialized code (as for ncurses 1a. -> 2.) and 1:1.

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

I think this is a secondary question - but yes, if things are done the
way they are now, that makes sense.

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

I was thinking in terms of those properties (I numbered them in order
to later refer to them, but then didn't actually make use of that).

     (1) The lynxkeycodes are assigned by lynx.

That is what's most obviously broken.  "Assigned by lynx" includes that
we can assign them any way we like, without having to pay attention to
restrictions imposed by other parts.

As long as that was the case, there was also no reason to make the
assignment dependent on the OS or curses library in any way.  And, since
Lynx code was free to do that, it chose as the most simple (and space-
saving) assignment stategy what I called "accidental property"

     (7) The lynxkeycodes are assigned sequentially.

which now also isn't true any more.

Related code was written in a manner that relied on those assumptions -
I am thinking here specifically of

   PRIVATE CONST char *funckey[] = {
     "Up Arrow",
     "Down Arrow",
     ...

(and the code that refers to it) for providing a mapping of the
extended lynxkeycode to readable strings, for the 'K'ey Map page.
There may still be other places; I think there were more, where
the dependence has been eliminated.

As long as Lynx was solely responsible for the assignment of those
lynxkeycode, there was also no reason to ever change them (I am not
talking about adding new ones).  That meant that they could be
referred to in the distributed lynx.cfg, which would remain valid
through upgrades, so that now we have (wild guess) hundreds of
thousands copies of lynx.cfg distributed that say

# Special keys map to:
#         Up Arrow: 0x100
#       Down Arrow: 0x101
#      Right Arrow: 0x102
#       Left Arrow: 0x103
#        Page Down: 0x104
#          Page Up: 0x105
#      Keypad Home: 0x106
#       Keypad End: 0x107
#   Function key 1: 0x108
# vt100   Help Key: 0x108
# vt100     Do Key: 0x109
# vt100   Find Key: 0x10A
# vt100 Select Key: 0x10B
# vt100 Insert Key: 0x10C
# vt100 Remove Key: 0x10D
#  (0x00) NULL KEY: 0x10E (DO_NOTHING)

Now, with the way DOS key mapping is done, there are two interests
competing for assignment in the lynxkeycode space 0x100 - 0xNNN.  It's
the weight of installed base and benefits of reusing existing code
(e.g. funckey above), against making it work at all for DOS.

Instead of making a clean cut, by saying "we do everything above 0xff
our own way" for DOS, the DOS code still uses some (or most; but not
all) of the pre-existing, "legacy" assignments.  Probably to get the
maximum of those benefits - compatibility with lynx.cfg files for most
keys (but not all), 'K'ey Map right for the most part...  Even if Doug
does his best to make this work, it seems to me this is still only a
compromise, it will still be wrong in some way for some keys.  And it
requires a difficult balancing act, currently performed by one person.

The two competing interests also stand in each others way when it
comes to future extensions.  Anyone wanting to add some new key
assignment (for the general case, without specific interest in the DOS
version) to the existing 0x100 - 0x10E definitions cannot just append
it at the end of that list without running the risk of conflict with
one of the DOS versions.  OTOH if some newer version of one of the
DOS libraries defined some new key codes in this region, again there
is a chance for conflict with already defined assignments.

Sorry, I don't really want to sound too negative, but it's pretty much
much conclusion that this is broken in principle, whether there are
enough tweaks to make it basically work or not.

I don't have a concrete proposal how to change it, but hope that this
is a useful discussion, something may come out of it.

   Klaus