lynx-dev
[Top][All Lists]
Advanced

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

lynx-dev Re: Minor patch for interrupting lynx


From: Ilya Zakharevich
Subject: lynx-dev Re: Minor patch for interrupting lynx
Date: Tue, 3 Oct 2000 17:23:59 -0400
User-agent: Mutt/1.2i

address@hidden 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 address@hidden

reply via email to

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