Re: lynx-dev Re: Lynx problems

[Jacob Poon]

On Wed, 13 Jan 1999, Kim DeVaughn wrote:

> On Wed, Jan 13, 1999, Bela Lubkin (address@hidden) said:
> |
> | I've been thinking about a related idea: a rolling buffer of status
> | messages.  Lynx would store in memory the last N status messages, N
> | being user-tunable.  There would be a special URL you could visit to see
> | those messages (e.g. lynxstatusline:); that might also be hooked into
> | e.g. the main help page.  It could also become a new key binding, but I
> | would recommend *not* making it one of the default bindings -- we have
> | so few keys left, this doesn't seem worth using one up.
> |
> | With the rolling buffer, users could choose to reduce all of the timers
> | to 1 second, and check the buffer if they missed anything.
> 
> Very good idea.
> 
> I often notice out of the corner of my eye the instant that a message
> flicks off (having missed seeing it appear), and then spend time trying
> to recreate/figure-out just what the heck it was.  Such a buffer would
> be quite useful, IMO.

What I would like to think though, is how to notify user that there are 2
or more lines in the buffer instead of just 1?  We can put an animated
cursor, or a visual symbol of some sort.  My idea looks like this: 

+------------------------------------------------------------+
|http://www.abc.com/                                         |
|<<99+    Alert!  Unable connect to remote host.            >|
+------------------------------------------------------------+
  ^                                                         ^
  +---how many lines of msgs in buffer.                     |
                    Current msg line is too long to fit. ---+

Splitting 2 lines has its advantages.  It will allow possible
multithreading between message display and navigation routines, with
minimal interference. And of course, it even leaves enough space for the
Javascript ticker animation.  :) 

But if screen space is at premimum, there is a one line variant of status
line:

             +----URI                Msg.--+
             v                             v
+------------------------------------------------------------+
|<<99+  http://www.abc.com/           Alert!  Unable connect>|
+------------------------------------------------------------+
   ^                                                        ^
   +--how many lines of msgs in buffer.                     |
                    Current msg line is too long to fit. ---+

In 1-line design, if URI is too long, the URI has higher priority of
occupying the entire status line.  However, it must still reserve space
for the indicator. 

If there are several message lines, only the last message is shown on
screen. 

> WRT the lack of available key-bindings ... has anyone given any serious
> thought to allowing lynx to utilize two character commands, where the
> 1st key (user definable, ESC, whatever) would act as a "meta" key?
> 
> That would alleviate the keyspace problem, and would allow commands like:
> 
>  ESC-a  = command foo
>  ESC-b  = command bar
>  ...
>  ESC-^Z = command baz
> 
> etc (where ESC represents the user-defined meta-key, whatever it may be).

Well, we can do an intermediate, vi approach for this.  For example,
typing ESC shows up a command line, then enter a command or set of
keystrokes to activate any Lynx's built-in commands.  This may not be as
elegant as the emacs approach, but before anyone can reengineer the key
binding routines, this is a more feasible alternative.