[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev "sticky" things, and a half-serious proposal
From: |
Klaus Weide |
Subject: |
Re: lynx-dev "sticky" things, and a half-serious proposal |
Date: |
Sun, 17 Oct 1999 19:44:51 -0500 (CDT) |
On Sun, 17 Oct 1999 address@hidden wrote:
> On Sun, 17 Oct 1999, Klaus Weide wrote:
> >> As much
> >> as I try not to use it as an example, this is how it works in the GUI
> >> world -
> >> left arrow in an edit field does nothing, but you can still tab to other
> >> fields to type in. My "modal but not noticable" discussion above is really
> >> just emulating what I consider reasonable user-focused behavior (do what I
> >> mean
> >> not what I say). lvirden has already said he doesn't think default
> >> behavior
> >> should be changed.
>
> Ok, I realize now I've lost this whole argument.. I still hope that this
> capability can be configured in (or turned off without recompile) -- that
> is, not ask me a question nor accidentally go back a page.
It isn't a technical problem to provide yet more behaviors, it is more
a question of configuration syntax complexity. (And, probably, "Is
just one key worth all this special attention".)
Well, I have come up with the ultimate option:
# The LAKABOFTIF option controls controls how lynx behaves when a
# Left Arrow Key is pressed while the text cursor is at the Beginning
# Of a Form Text Input Field (in line-edition mode). The normal behavior
# of the Left Arrow key is to return to the previous document in browsing
# history (PREV_DOC). This option can be used for setting various different
# behaviors in the specific situation, to prevent accidentally leaving
# the current document when you didn't mean to.
# LAKABOFTIF takes directives in the form 'action=condition', several of
# these can be given separated by comma. Condition is one of:
# NEVER - never do this (same as omitting 'action' altogether)
# ALWAYS - always do this
# IF_CHANGED - if the current text input field was edited
# IF_NOT_EMPTY - if the current text input field is empty
# IF_FORMS_CHANGED - if *any* form fields in the current page were changed
# Action is one of:
# PROMPT - Lynx will ask what to do, giving a choice of going to the
# previous document or staying in the input field.
# IGNORE - The key is ignored, and the cursor remains in the input field.
# BEEP - The key is ignored as for IGNORE, additionally lynx tries to
# produce and audible warning.
# COMMIT - The last editing changes (if any) will be committed, instead
# of being forgotten, even if lynx exits from line editing to
# return to the previous document. This is useful in case you
# return later to the current document while it is still in
# memory, for example by following a forward link again.
# If several 'action=condition' pairs are given, [ ...to be filled in... ]
# If no LAKABOFTIF option is specified, the default is to PROMPT
# if the input field has been changed, and to never IGNORE or BEEP.
# If the option is present but empty, i.e. just 'LAKABOFTIF:', The Left
# Arrow key always has its PREV_DOC meaning (or other, if changed with
# a KEYMAP options).
#
#LAKABOFTIF:PROMPT=IF_CHANGED
Do you like it? :)
Speak it loud several times: lakaboftif, and you'll never forget it for
the rest of your life... (seriously, I find it easier to remember such
an artificial word than which-is-which among STICKY_INPUTS and
STICKY_FIELDS.)
> >But lynx is really quite different form the GUI world. With mouseclick-
> >browsers one doesn't need the Left Arrow key for navigation between
> >documents, but in lynx it is *the* way for going to the previous document.
>
> But command-arrows _do_ go back pages, and that's the equivalent of what
> you're doing in Lynx with arrows.
If you *want to* use something like "command-arrows" (not sure what that is,
probably because I am not a Mac user...) for navigation, then it should be
possible to tweak lynx to never use noncommand-arrows for navigation.
It may already be possible, with the right set of KEYMAP: and ~/.lynx-keymaps
settings. That would depend on how lynx receives the "command-arrow" keys.
I would just find it very annoying to always have to press some modifier
key with the cursor keys, but that's just me (and all other "traditional"
lynx users...).
> Yes, I don't want people stuck in a page -- isn't this completely broken
> HTML though?
It would be inconvenient (and inconsiderate), but not necessarily broken
in a technical sense.
Klaus
- Re: lynx-dev "sticky" things, (continued)
- Re: lynx-dev "sticky" things, Rick Lewis, 1999/10/16
- Re: lynx-dev "sticky" things, Klaus Weide, 1999/10/16
- Re: lynx-dev "sticky" things, Vlad Harchev, 1999/10/16
- Re: lynx-dev "sticky" things, Klaus Weide, 1999/10/16
- Re: lynx-dev "sticky" things, Janina Sajka, 1999/10/16
- Re: lynx-dev "sticky" things, Klaus Weide, 1999/10/17
- Re: lynx-dev "sticky" things, mattack, 1999/10/16
- Re: lynx-dev "sticky" things, Klaus Weide, 1999/10/17
- Re: lynx-dev "sticky" things, Leonid Pauzner, 1999/10/17
- Re: lynx-dev "sticky" things, mattack, 1999/10/17
- Re: lynx-dev "sticky" things, and a half-serious proposal,
Klaus Weide <=
- Re: lynx-dev "sticky" things, and a half-serious proposal, Vlad Harchev, 1999/10/18
- Re: lynx-dev "sticky" things, and a half-serious proposal, Klaus Weide, 1999/10/18
- Re: lynx-dev "sticky" things, and a half-serious proposal, Vlad Harchev, 1999/10/18
- Re: lynx-dev "sticky" things, and a half-serious proposal, Klaus Weide, 1999/10/18
- Re: lynx-dev "sticky" things, and a half-serious proposal, Vlad Harchev, 1999/10/18
- Re: lynx-dev "sticky" things, and a half-serious proposal, Klaus Weide, 1999/10/18
- Re: lynx-dev "sticky" things, and a half-serious proposal, Leonid Pauzner, 1999/10/18
- Re: lynx-dev "sticky" things, Leonid Pauzner, 1999/10/16
- Re: lynx-dev "sticky" things, mattack, 1999/10/16
- Re: lynx-dev "sticky" things, Vlad Harchev, 1999/10/16