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

[Leonid Pauzner]

13-Nov-99 21:18 Klaus Weide wrote:
> 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).

Thanks, Klaus, that is the most logical way: to have ^X as a common
prefix for texarea-specific actions, and leave ^V for real escapes of
main actions. But how that could be written in lynx.cfg?

> 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