Re: lynx-dev Lynx problems

[Bela Lubkin]

Jacob Poon wrote:

> Version: Lynx 2.7.2 (Solaris/Sun)

This is an old version.  One of the issues you mention is fixed in the
current version.  ftp://sol.slcc.edu/pub/lynx/current/.

> Bugs
> ====
> 
> Incomplete URI caching
> ----------------------
> 
> Problem:  If I enter an incomplete URI, entering the incomplete version of
> the initially expanded URI will cause Lynx not to look up the URI in
> cache. 
> 
> Examples:  Type 'www.award.com' will cache 'http://www.award.com/'.  But
> next time if I type 'www.award.com' or 'http://www.award.com', Lynx will
> not load the cached 'http://www.award.com/'.

I tested this on Lynx 2.8.1rel.1, which is itself an old version.  The
cache worked as you request.

> Error message delay
> -------------------
> 
> Problem:  Lynx's error messages delay feature sometimes interrupts the
> background process, resulting delay of service.
> 
> Examples:  
> 
> If I get a 404 error when I retrieve a page, I am forced to wait for
> several seconds before Lynx displays server's automatic response.  And I
> cannot bypass the delay at all.
> 
> Solutions:
> 
> First of all, setting the delays to zero will not solve my problem because
> I may still want to see Lynx reports the error.  But at the same time, I
> do not want Lynx stopping the background processes or interrupting
> transfers (in case 1, displaying server's automatic response on error 404)
> to slow down my browsing speed. 
> 
> Therefore lynx.cfg settings, INFOSECS, MESSAGESECS, ALERTSECS, should be
> implemented in following manners (following is INFOSECS psuedo-code, but
> it should be trivial to replace it for MESSAGESECS and ALERTSECS designs):
> 
> showINFOSECS (int INFOSECS) {
>   showmsg(errno)
>   if INFOSECS < 0 then
>     loop
>       exit if a_key_is_pressed()
>     end loop
>   else
>     timer = 0
>     start_timer(timer)
>     loop
>       exit if timer > delay_time
>       if a_key_is_pressed() then exit loop
>     end loop
>     stop_timer(timer)
>   end if
>   erasemsg()
> }
> 
> This implementation allows all messages at the status line to be skipped
> by a keystroke, without having to wait for the delay.  In addition, the
> delay functions should not disrupt any other background activities such as
> screen update or data transfers.  Negative value for INFOSECS,
> MESSAGESECS, or ALERTSECS in lynx.cfg means the corresponding status line
> message will not go away until a key is pressed, which I recommended for
> the slowest to the fastest readers, under this implementation.

I agree that Lynx's status line handling is annoying, but your
suggestion would be even more annoying.  It would interfere with
typeahead.  Suppose a status line is displayed; I want to issue the next
command.  I may hit "space" to clear the status line, followed by my
command.  But suppose there was actually a second status message
following the first?  My command would be eaten.

Long ago, someone wrote code which ran the status messages
asynchronously: they would still display just as long as now, but
wouldn't prevent further user interaction.  This seems like a good
thing.  What ever happened to that patch?

=============================================================================

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.

>Bela<