lynx-dev Re: Keys, an attempt to understand

[Kim DeVaughn]

On Thu, Feb 11, 1999, Klaus Weide (address@hidden) said:
|
| On Wed, 10 Feb 1999, Kim DeVaughn wrote:
| >
| > 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 &&

Ignore most of this rant (see below):

  [Certainly the refresh operation is important, but I fail to see why any
   key needs to be picked-off early in the food chain, to perform it.  Or
   why *any* key needs to be picked-off early for "special handling", for
   *any* function.

   I can understand the choice of doing so with ^L, for historical reasons
   (and that ^L == FF).  Indeed, many apps do that for ^L (not that I think
   that that is any justification for lynx to hard code it to perform
   refresh).

   But I don't know of another app that does that for TWO different keys!
   And why in the world was a ^W (^W == ETB, forgodsake) chosen?  Makes
   absolutely NO sense to me.

   In your trip through the keybinding mess, did you happen to notice if
   there are other such hard-coded keys/functions?

   <something clicks in my head, just about now>
  ]

Flash ...!

I just discovered that one *can* rebind both ^L and ^W with a lynx.cfg
KEYMAP statement.  [I guess I never tried doing that, because of my
failed attempt to get ^W to rebind to a different lineedit function.]

Now I'm really confused.  I cannot change the ^W behavior in LYEditmap.c
at compile time, if it is bound to the default LYK_REFRESH action at
run time.  OK ...

But I *can* rebind it at the KEYMAP level for non-lineedit usage, which
then appears to leave it NOP'd when used in lineedit mode (or I suppose,
to whatever LYE_function it was compiled with).

I'm beginning to see.  I think.  It isn't the "lynxkeycode" that is hard
coded here, but the "lynxactioncode", which then affects the attempted
binding of the "lynxkeycode" to some "lynxeditactioncode", if (and only
if ?) that "lynxkeycode" happens to be bound to LYK_REFRESH, for the
non-lineedit use.  Or something like that.  I think.

I suppose I will need to try an experiment or two, to see if I have that
straight now.

Sheesh ...


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

See above (if *I* made any sense).


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

Actually, I was thinking more along the lines of lynx assuming (possibly
mistakenly) that some keystrokes have "special meanings" outside of lynx,
when it (lynx) is running.

Eg: the stty defs for 'rupt generating functions like dsusp, intr, kill,
quit, susp, etc.  Then there are our old-time friends XON/XOFF (^S/^Q).
And similar such things.

To further clarify, my stty for quit is ^\, yet lynx is ignoring that,
leaving me to bind ^\ as I so choose.  I dunno why that is [if other
explanations fail, blame it on the termcap :-) ].

As to the ^V thing ... I dunno.  I don't find any "quote key" in the
stty settings, but I *do* find one for may shell (tcsh), and by default,
it is ... ^V.  Even so, *I* don't have to do anything special to use
^V as it is intended to be used within lynx, but at least one user on
the list (LV) is certainly having problems, and needs to ^V^V it.


Point being, it is those kind of things that really complicate the whole
keybinding morass, lynx internals aside.

/kim