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

[Klaus Weide]

On Thu, 11 Feb 1999, Kim DeVaughn wrote:
> 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):

But not all... :)

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

It's a VMS convention, as far as I remember.  A lot of Lynx development was
done on VMS for a long time... if it hadn't been, Lynx might be dead now.

And it's not like the various uses of control chars in Unix systems
are on the whole more logical, or have more to do with the original
ASCII meanings...

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

Is it enough if I answer with Yes? :)
See below for another case.

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

Yes, I agree with your description.

You _can_ implement some lineedit function like delete-prev-word for
^W in your edit map, and if you don't have ^W mapped to LYK_REFRESH,
that function will become available.  As long as ^W is mapped to
LYK_REFRESH it is effectively hidden.

The logic seems to be that a user mapping for REFRESH should be stronger
than what might be in the edit map.  It would be easy enough to change,
if that's what we want to do.

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

Here I was thinking more about what happens under "case F_OPTION_LIST_TYPE:"
in LYForms.c - where ^L and ^R are hardwired to pass something along to
mainloop() that goes beyond just "do a refresh" - there's a least two kinds
of refreshes it seems.

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

I guess I have to take back that this isn't so important, since more than
one person seem to have reeported problems of this kind lately.

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

I think the defaults are just playing it safe.  You may or may not be able
to use some or all of those keys on a specific system, in a specific
situation, but it's not always possible, so they are left unassigned.
But, as you noticed, you can use some of them just fine.

My system doesn't even have something like dsusp, and I can use ^Y as
I like, but not ^\.

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

Or more likely, termios or similar.  And which flags curses does or
does not set when start_curses is called.

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

The shell is not in control while Lynx is running, so what it has for a
quote key is really quite irrelevant.

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

Yep and I don't, even though stty -a says lnext = ^V.  Some systems
just act different than others.

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

But I prefer to regard them as two separate morasses, that makes it easier
to deal with each.

   Klaus