Re: lynx-dev Keys, an attempt to understand

[Klaus Weide]

On Wed, 10 Feb 1999, Doug Kaufman wrote:
> On Wed, 10 Feb 1999, Klaus Weide wrote:
> 
> > 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.
> 
> This was because of the special handling of the ARROW keys that
> you mention below. There are enough special cases for them that
> having the arrow keys map to anything but the standard lynx code
> seemed like asking for trouble. Certainly, I didn't feel up to doing
> all the changes to the rest of the code to allow mapping of the
> lynxactioncodes associated with the arrows.

Hmm, there doesn't seem to be anything though that depends on them
having specific numeric values, except the funckey[] table.  Except
for the purpose of that table, you could have dealt with the code
referring to DNARROW and so on by changing the macro #defines in
LYStrings.h.  (I'm not saying you should have - it's just something
I would have expected before looking closer.)

> > 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",
> >      ...
> > 
> > ... 
> > # 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
> 
> The above keys are mapped this way in the DOS port via the code in
> LYStrings.c. F1 is mapped differently, but I didn't see special code
> for its handling. The DOS keyboard doesn't have any of the special
> vt100 keys mentioned below.
> 
> > #   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)

But the DOS keyboard should have Ins(ert) and Del(ete), which should
map to 0x10C and 0x10D.

> > 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.
> 
> There are lots of potential keys that can be mapped on the DOS keyboard.
> If lynx needs certain keycodes, these can be take off the DOS mapping
> via the switch code in LYStrings.c

That's part of what I meant below with balancing act...

> > 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.
> 
> I have no special expertise in this area.

It's all just some tables and switches...

> I just wanted to be able to
> use the KEYMAP function in lynx.cfg with the DOS extended keys. At the
> time, any keycodes over DO_NOTHING (0x10e) were mapped to '0'and were
> not in the keymap[] from LYKeymap.c. 

I understand why - I might have done the same.

> I expanded this for DOS without
> considering that others might want to use this space in the future. 

Understandable, considering that the space never *was* extended (in a
long time).  I don't now whether it will be extended more now, at least
it should remain possible.

> If anyone wants to improve this, please feel free.
>  
> > 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.
> 
> I don't think that this has to be a problem. We would just change
> those conflicting DOS key assignments through the switch code. 

As long as there's some advocate for the DOS cause around who keeps
a watchful eye...

> If
> the new lynx keycodes don't have to be consecutive, there are lots
> of unused places in the mappings. 

It's at least ugly to have to look at three different tables, in order
to make sure a code is not taken.  Also (again), the tables might
change.

> Which parts of the code depend on
> definitions being consecutive?

At least this, in pretty():
        else if (c >= 0400 && (c - 0400) < (int) TABLESIZE(funckey))
                sprintf(buf, "%s", funckey[c-0400]);

Maybe not more, maybe yes - we can try to break it and see what happens :)

> > 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 am still amazed that lynx works in DOS at all.

Yes :)

Some other potential breakage: you haven't extended the maps in
LYEditmap.c in the same manner as keymap[].  I think that should
be necessary, or the keys after DO_NOTHING will be mapped to
arbitrary garbage.

The DOS and Windows varieties of keymap[] have DO_NOTHING mapped to 0.
Therefore I'd expect all DOS versions to have the same missing
statusline behavior that started this whole thing in the 'Nitsy
"reset"' thread.


   Klaus