lynx-dev
[Top][All Lists]
Advanced

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

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


From: Leonid Pauzner
Subject: Re: lynx-dev Re: Final dev15 patch for TEXTAREA edit feature (I hope)
Date: Fri, 5 Feb 1999 19:59:44 +0300 (MSK)

5-Feb-99 07:02 Kim DeVaughn wrote:
> 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).

In your case any quote for "key" in the documentation should be referenced so,
like this: "for O)ption menu try the key mapped for it (default is "o").
That is a nonsence. Anyway, my comment to lynx.cfg should be applied.

> Note that references to UP/DOWN arrow keys, etc, are also hardcoded,
> even though they too may have been rebound.
yes, if someone decide to remap any important key he should do a huge job
to make things correctly.

> | -     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.
Well, yes.
We mean "input, type=text" and "textarea" fields
which are supposed for user input from keyboard.
I mean a word "input" should be intuitive for less technical users
(and so was in all previous versions) but seems your wording
looks more accurate here, especially since that help pages
intended for line editing (=always input, no buttons).
Sorry.


> 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.
User may try ^Vh for help from (single line) input text field
just to see key binding map, no?

> I chose "text areas" rather than "TEXTAREA field" as probably being less
You have "text area" for one help page and "textarea" for another, typo.
> 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



reply via email to

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