[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev Lynx problems
From: |
Bela Lubkin |
Subject: |
Re: lynx-dev Lynx problems |
Date: |
Wed, 13 Jan 1999 19:06:07 -0800 |
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<