[Top][All Lists]

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

Re: lynx-dev Which key for textarea external editor?

From: Klaus Weide
Subject: Re: lynx-dev Which key for textarea external editor?
Date: Fri, 19 Nov 1999 06:12:06 -0600 (CST)

On Sun, 14 Nov 1999, Kim DeVaughn wrote:

> On Sat, Nov 13, 1999, Klaus Weide (address@hidden) said:
> |
> | [...]The fact
> | actions today is nothing but a kludge, necessitated by the way the lynx
> | code worked - not by logical interface design. [Kim, do you disagree? :)]
> Nope, not at all.  When I implemented those functions, I just didn't
> see any way to (easily) restrict their "availability" to TEXTAREA's
> alone.

Well with ^Xe (or ^X^E or ^E^E or ...) the "availability" is still not
restricted to TEXTAREAs.  But it is at least limited to Line Editing
of form fields.

> | ^V==LKCMD is for "give me a way to make a key do what it would do if I
> | were not in a form field".  It makes little sense to use this for actions
> | that have only meaning in form fields.)
> Are you suggesting having *both* ^V and ^X active as "meta-keys" when one
> is in a TEXT/TEXTAREA field?

Yes indeed, if you want to express it that way[*].  As has been the case
since 2.8.3dev.1.  It seems you have missed a lot (basically, all) that has
has been going on in this area...  Should I have just messed with your
"Alternative Bindings", rather than making a new "Bash-like" for the
new features, to get your attention earlier? :)

[*] I would prefer to use "meta" only for the more specific function, i.e.
^X (or ESC) not ^V.  ^V is a "command escape key" (as I think you called
it earlier).

> While I agree that one can interpret the meanings differently (ie, ^V to
> mean "the next key is a normal/global lynx command", and ^X to mean "the
> next key is a TEXTAREA-specific command"), that seems to be overkill, and
> possibly confusing.

No, ^X is not a TEXTAREA-specific mechanism.  It is for all Line Editor
uses, including entering 'g'oto URLs etc., although some functions that may
be bound to extended ^X<something> keys obviously make no sense in non-
formfield contexts (and get ignored).

> Rather, I'd suggest *replacing* ^V with ^X for the simple reason that some
> shells eat a singlr ^V, which has resulted in the need for some users to
> use ^V^V in order to obtain the desired "meta-action" intended by a ^V in

I view that as a separate problem.  Not such a big deal in my opinion;
big enough to not require ^V for new important functions, but not big
enough to absolutely get rid of ^V.  ^V as "command escape" is not
essential.  For a long time lynx was doing fine without such a key.
In some (infrequent) situations it helps for escaping from being "trapped"
in a form field.  But then, most users have a Left Arrow key or some
other non-letter key that can be used to escape the trap, except in the
most unusual situations.

> Doing so would also unload the ^V overload, where it "normally" means
> SWITCH_DTD, unless you are in a TEXT/TEXTAREA ...

A separate problem, and one that can be solved on a personal basis by
mapping SWITCH_DTD to some other key (and making KEYMAP:^V:DO_NOTHING
if you like).

You cannot currently remap the Line Editor action of ^V (i.e. "command
escape *from* the Line Editor") in lynx.cfg.  But it should become
possible soon, by extending Ilya's recent patch.

> | Btw. I am still thinking of giving EDIT a meaning for remote documents,
> | along the lines of the LYK_SCRIPT idea/patch of a while ago.  That
> | would mean that "e" does have a useful function in remote documents
> | (other than producing a "Lynx cannot currently (e)dit remote WWW files"
> | message).  That function should of course be accessible in a form text
> | field with ^Ve.
> That sounds interesting, and for consistency would argue *for* seperate
> meta-keys (^X and ^V).

Yes indeed.  Not that it creates a completely new need for
<command escape>EDIT - you never seem to have wanted to edit a local HTML
file with forms...

> Unfortunately, ^V will still be a problem for some folks, requiring the
> dreded double-^V.  So perhaps if two meta-keys are indeed worthwhile, we
> can still find something other thab ^V for one of them ...?

If that's a problem you want to have solved, keep pushing...
But if nothing tells the user to use "^Ve for editor" (or ^V<this> for
[that important function]) then it becomes less important.  I prefer
to solve 'technical' problems rather than the 'political' one ("what
should be the binding for function x in the next release?").


reply via email to

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