lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev Keys, an attempt to understand


From: Doug Kaufman
Subject: Re: lynx-dev Keys, an attempt to understand
Date: Wed, 10 Feb 1999 22:23:09 -0800 (PST)

On Wed, 10 Feb 1999, Klaus Weide wrote:

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

I agree. I just thought that conceptually they were still separate.
 
> 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.

> ... 
> 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)
> 
> 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
 
> 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. 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 expanded this for DOS without
considering that others might want to use this space in the future. 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. If
the new lynx keycodes don't have to be consecutive, there are lots
of unused places in the mappings. Which parts of the code depend on
definitions being consecutive?

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

                                Doug
__
Doug Kaufman
Internet: address@hidden (preferred)
          address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]