lynx-dev
[Top][All Lists]
Advanced

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

LYNX-DEV Re: FAQ update


From: Al Gilman
Subject: LYNX-DEV Re: FAQ update
Date: Wed, 27 Nov 1996 21:39:39 -0500 (EST)

I looked at the "keystroke" section you have fleshed out.

1.  So far it ignores links-are-numbered mode.

2.  The language "The definitive list of key definitions" is
going to lead people to misunderstand.  The key/function bindings
in the list you have linked to is quicksand, not something one
can count on.  Only your dynamic K)eymap command is definitive,
because the keystrokes are totally re-programmable.

2.a.  Actually, the page you have linked to, there, could use some
work.  In explaining the keystroke _functions_, they should be
ordered by function name, not default key binding.  It is good
for the dynamically generated KEYMAP page to be alphabetically by
key.  But the list in the static Help page should be by function,
not by key, because the keys can change, and more fundamentally
because the H)elp question is more often "what is the key to do
X?" than it is "What does the Y key do?"  Your tables are a step
in that direction.  

2.b.  Are y'all planning to take the existing help files under your
wing?  There are lots of modest reforms one could apply to the
h)elp, like cross-linking between the related topics in the
keystroke paragraph and the command-line paragraph, where the
same degree of freedom (e.g. IMAGE_LINKS) is affected.

--

3.  Miscellaneous, potentially obscure points:

        What link the cursor winds up on 

                when using text-based motion commands

                when moving as a result of a WhereIs (/) query

        analogy between anchor-to-anchor navigation
        and hit-to-hit motion via n)ext-hit after
        a WhereIs


        The navigation paragraph needs to warn the user
        that all these keys _usually_ work, but that
        when they stop working you need to
        (navigation out of form traps).

--

4.  The interactive manipulation of user options is a major topic
I don't see in your (top-level) list. -- linked to offline
manipulation of lynx.cfg and at compile time.

Al Gilman

        
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;

reply via email to

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