lynx-dev Re: Final dev15 patch for TEXTAREA edit feature (I hope)

[Kim DeVaughn]

On Fri, Feb 05, 1999, Leonid Pauzner (address@hidden) said:
|
| >  4. Attempting to edit (^Ve) a TEXT field (not a TEXTAREA), is now
| >     blocked, with the user getting an error msg.
|
| Just a minore wording - please apply this patch after yours.
| I hate numerous statements of "mapped to... by default":
| the non-default case assumed to be a special case,
| I add a note in lynx.cfg instead of trying to push
| every user to check mapping.

Sorry, but I disagree.  I think referencing "default ___" is a good
reminder to people that they may change (or may *have* changed) a
configurable element, when it is possible to do so in a convenient
manner (eg, in documentation).


| (BTW, "^Ve" seems to be frozen into a status message)

Correct.  It isn't 'convenient" to try and check through the bindings
and find the current key binding to insert into the statusline message
(though it *could* be done, were it not for gettext(), et`al).

Nor is it easy to word the message in a more general way, and *still*
keep it <= 79 or 80 chars (eg, "^V* where * is the key bound to the
EDIT function").

Note that references to UP/DOWN arrow keys, etc, are also hardcoded,
even though they too may have been rebound.


| -     LKCMD  Invoke cmd prompt     -  Ctrl-V (in form text areas, only) [2]
| +     LKCMD  Invoke cmd prompt     -  Ctrl-V (in form input fields, only) [2]

That isn't correct.

There are other "form input fields" where ^V isn't (or shouldn't be) an
escape ... a form TEXT field being the obvious example (which has now
been disabled WRT ^V escape).  Only a TEXTAREA field is valid, AFAIK.

I chose "text areas" rather than "TEXTAREA field" as probably being less
confusing to the less technical users.  Using "input fields" though, is
not only incorrect, but is misleading, as it implies a capability that
just isn't there.  IMHO ... :-) ...

/kim