Re: lynx-dev Re: Keys, an attempt to understand

[Klaus Weide]

On Wed, 10 Feb 1999, Kim DeVaughn wrote:
> On Tue, Feb 09, 1999, Klaus Weide (address@hidden) said:
> |
> | Basically and "originally", we have two levels of mapping:
> |
> |     1.                  2.                    3.
> |
> |         byte sequence  ---> lynxkeycode      ---> lynxactioncode
> |                                          (or ---> lynxeditactioncode)
> 
> | I leave out examples of deviations from the ideal here, as well as probable
> | reasons for them and for the "accidental" properties.  We could get into
> | that later.
> 
> By this, are you refering to cases where the "lynxkeycode" (or possibly
> even the "byte sequence") are picked off for "special actions", and never
> make it to the level-3 mapping?

I was thinking mostly about different keys being mapped to the same
lynxkeycode, i.e. breakage of

  (3) Distinct keys have different lynxkeycodes.

For example an F1 and a HELP key are handled as if they were the same
thing, or a CLEAR key like ^R, and various things like that in LYgetch.

> For example, my own experience at an attempt to remap the ^W slot to
> something other than LYE_NOP (which is an incorrect/misleading binding,
> in and of itself), to a different "lynxeditactioncode" was unsuccessful
> (^W still performed the REFRESH action).

Well that shows that my model is too simplistic...  In the case of ^W,
this is probably due to the explicit "if (keymap[ch + 1] == LYK_REFRESH)"
checks in LYgetstr and form_getstr.  In the latter this is mentioned
explicitly:
        /*
         *  Filter out global navigation keys that should not be passed
         *  to line editor, and LYK_REFRESH.
         */
Apparently it was regarded more important to make sure that ^L / ^W
always refreshes, than to make it changeable.  I can understand that
somewhat, I makes sense in an environment where there is a high chance
of getting something written to the terminal that Lynx doesn't know
about, or maybe with some kinds of unreliable remote connections.
Maybe the test could be changed to "if (keymap[ch + 1] == LYK_REFRESH &&
action == LYE_NOP)" (in the case of form_getstr) or something equivalent.

> I can't think of any good reason for such early pick-offs (though I
> imagine there are some), but it certainly complicates the above model.

Actually I didn't mean the model to say when which of the 2. ->
3. translations takes place, or to exclude passing things from one
function to another, so the specific case above (if I understand right
why it happens) would still be within.  The special treatment that 23
(^W) gets in mainloop() is maybe a different story.  But that stuff
about refreshing is scary.  I guess there is some reason to treat ^W
different from ^L although both are mapped to the LYK_REFRESH action,
I remember dimly that it has to do something with the behaviour of
various curses packages (including slang, VMS curses, ...).  It would
probably be cleaner to introduce a LYK_ALTREFRESH and map one of the
keys to that.  Or even a PSEUDOREFRESH lynxkeycode, for the sole
purpose of passing it around, so that the real ^L or ^W could be
remapped independently.  (I don't know whether I am making much sense
here...)

> Also, while not any part of lynx, but the source of many *user* questions,
> and/or frustrations, is the level  0 --> 1  mapping/filtering that you've
> omitted, wherein the OS/shell/whatever picks off a keystroke/byte-sequence
> for its own action, and never even presents it to the application (eg,
> stty settings, etc).

I didn't get the impression that this is so frequent - I don't really
know what you are referring to other than the ^V.  In a telnet
connection ^] (normally) is picked up as an escape, there are other
special escapes when using rsh / ssh / comm programs like kermit /
screen, but users of those supposedly know about that (or find out
quickly).

> Not strictly relevant to your discussion/model, but something that should
> be kept in mind, nevertheless (ie, are there implicit assumptions about
> whether the "byte sequence" lynx is getting is "cooked" or "raw"?).

Well, if (for Unix) the tty were in "cooked" mode, bytes would reach lynx
only after you press enter (or maybe ^J).  It's part of start_curses's
job to put the tty in some "rawish" mode, and then curses's job to keep
it that way.  In my playing with ^Z I had cases where it got confused
about that, but I don't think it "normally" happens often.

      Klaus