[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
> | that INSERTFILE/GROWTEXTAREA/EDITTEXTAREA *are* KEYMAP-bindable main
> | 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
> a TEXT/TEXTAREA.
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?").
Klaus
- lynx-dev Which key for textarea external editor? (was: textarea no wrap ...), (continued)
- lynx-dev Which key for textarea external editor? (was: textarea no wrap ...), Klaus Weide, 1999/11/10
- Re: lynx-dev Which key for textarea external editor?, Philip Webb, 1999/11/10
- Re: lynx-dev Which key for textarea external editor? (was: textarea no wrap ...), Leonid Pauzner, 1999/11/11
- Re: lynx-dev Which key for textarea external editor?, Klaus Weide, 1999/11/13
- Re: lynx-dev Which key for textarea external editor?, Philip Webb, 1999/11/13
- Re: lynx-dev Which key for textarea external editor?, Klaus Weide, 1999/11/13
- Re: lynx-dev Which key for textarea external editor?, mattack, 1999/11/15
- Re: lynx-dev Which key for textarea external editor?, Klaus Weide, 1999/11/13
- Re: lynx-dev Which key for textarea external editor?, Leonid Pauzner, 1999/11/14
- Re: lynx-dev Which key for textarea external editor?, Kim DeVaughn, 1999/11/14
- Re: lynx-dev Which key for textarea external editor?,
Klaus Weide <=
- Re: lynx-dev Which key for textarea external editor? (was: textarea no wrap ...), Kim DeVaughn, 1999/11/11
- Re: lynx-dev Which key for textarea external editor? (was: textarea no wrap ...), Klaus Weide, 1999/11/11
- Re: lynx-dev textarea no wrap but horiz scroll with form=virtual, Kim DeVaughn, 1999/11/11
- lynx-dev return from textarea editing (was: textarea no wrap ...), Klaus Weide, 1999/11/11
- Re: lynx-dev return from textarea editing (was: textarea no wrap ...), Kim DeVaughn, 1999/11/12
- Re: lynx-dev return from textarea editing (was: textarea no wrap ...), Klaus Weide, 1999/11/13
- Re: lynx-dev return from textarea editing (was: textarea no wrap ...), Kim DeVaughn, 1999/11/14
- Re: lynx-dev return from textarea editing (was: textarea no wrap ...), Klaus Weide, 1999/11/19
Re: lynx-dev textarea no wrap but horiz scroll with form=virtual, Klaus Weide, 1999/11/10