lynx-dev
[Top][All Lists]
Advanced

[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: Sat, 13 Nov 1999 21:18:22 -0600 (CST)

On Thu, 11 Nov 1999, Leonid Pauzner wrote:

> Reading feedback, seems the consensus reached:
> ^E^E as default mapping for any key binding table,
> also ^Xe for those who use bash-like binding (at least).
> 
> The latter fall down to the old problem: meaning of "e" is not the same
> as "e" outside of input field. That is overloaded (EDIT/DWIMEDIT) which
> may lead to confusion (or not).

Another remark; don't think of it as 'meaning of "e"'.  Think of it as
'meaning of ^Xe' and nothing more.  Regard ^Xe as a unit.  It's only
accidental that there's an "e" in it (although obviously useful as a
mnemonic).  It could be ^Xy (for any letter y) and this would be
completely independent of the meaning of "y" as a standalone command
key.  Examples already in Bash-like bindings: ^Xi invokes INSERTFILE
function; this is independent of main binding for "i".  ^Xg invokes
GROWTEXTAREA function; again this is independent of main binding for "g".

(In fact, if all lineedit bindings have these, there is no need for
having INSERTFILE/GROWTEXTAREA/EDITTEXTAREA as main (non-lineedit)
actions at all - they never make sense if not in a textarea.  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? :)]
^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.)

Users will see "(^Xe for editor)" on the statusline.  They are not
supposed to analyze this into components, like '"e" is for <..>, and I
need ^X to make "e" really do <..>'.

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.

   Klaus


reply via email to

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