[EMAIL PROTECTED] wrote:
> How "should" the ESC key work?
Let us start with what it does now: it blocks Lynx forever (or until
the next key is pressed, whatever comes first ;-).
My immediate Esc-related plans are:
x) Proceed as now unless ESC is bound to DWIM_INTERRUPT (or whatever);
[But this may be changed too. Say, with ncurses, if Esc reaches Lynx,
there is a very good chance that it is *not* a part of a control
sequence, so the current block-until-you-got-next char behaviour can
be disabled. In general (other "screen"s), it deserves *at least* a
timeout.]
The rest assumes that a key bound to DWIM_INTERRUPT arrives:
x) When Lynx is in a middle of a long-running operation, behave as
with C-g (interrupt it);
x) When processing a command input, erase it if non-empty, otherwise
cancel;
Suppose that by default entries are in a READONLY state (so "behave as"
ordinary links), and to start editing an ENTRY you need to press
ENTER. Then
x) When editing an entry field DWIM_INTERRUPT switches back to
"non-editing" mode (as ^V does now?).
Possibly (regulated by a flag, or on DWIM_INTERRUPT_OR_PREVDOC):
x) When in a non-editing mode, go to the previous page.
This is best to be combined with an UNDO_PREVDOC action (not
implemented yet?), to guard against accidental presses.
Note that this frees Left and Right to perform more meaningful
actions, like what I have now: LEFT_LINK/RIGHT_LINK (and
LPOS_PREV_LINK/LPOS_NEXT_LINK for Up/DOWN).
Ilya
; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to [EMAIL PROTECTED]
