lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev Keys with partial


From: Klaus Weide
Subject: Re: lynx-dev Keys with partial
Date: Thu, 5 Aug 1999 15:25:21 -0500 (CDT)

On Thu, 5 Aug 1999, Philip Webb wrote:
> 990804 Klaus Weide wrote: 
> > On Thu, 5 Aug 1999, Ilya Zakharevich wrote:
> >> What is the logic behind nost navigation keys not working
> >> with partial display set?  Most importantly, arrow keys,
> >> but mouse would be nice as well.
> > Many navigation keys don't make sense
> > in a state where there is no notion of "current link".
> 
> you dismiss the suggestion too cursorily.

It was a question.  He was asking for "the reason behind".
I gave one.

It seems you dismiss my reply too cursorily.

> often i find myself waiting for a newspaper document to finish arriving,
> knowing i want to enter eg  /marker  to goto the start of the text
> -- newspapers have very predictable layouts day-by-day -- ,
> but  /  &  n  are not seen by Lynx if there's any pause in transmission
> -- & so have to be repeated -- & neither work during transmission itself.

Note (1) I said "many navigation keys" (not all), (2) I don't regard '/' as
a "navigation" key.

If you just wish lynx had a "longer memory" for typed-ahead keys - so that a
'/' key would be acted upon not immediately but after loading finishes -
that is a different topic.

> >> A reasonalbe behaviour of LEFT and RIGHT might be
> >> to interrupt the transfer as if 'z' was pressed.
> > Please no.
>  
> maybe you didn't stop to understand:
> eg i'm downloading a long index document from a newspaper
> & know i want to follow link [45]:  45g Enter Enter  would be nice to have;

This "nice to have" is completely different from the suggestion that
I replied to with "Please no".

> also, i may already know i don't want this document
> &  Left-arrow  is slightly quicker than  z Left-Arrow .

Just "is slightly quicker" is not enough to make it "reasonable behavior".
We also don't make Left-Arrow within the first document exit lynx
automatically[*], although that would be "slightly quicker".

Interrupting a network tranfer should be a deliberate action, not
something likely to happen accidentally.  Just imagine what would
happen if you hold down Left-Arrow a bit too long (I assume your keys
autorepeat) if a 'z' is implied.  Suddenly multiple transfer requests
get started and immediately aborted.  In the worst cases (slow
connection, timing, an imperfect local proxy thrown in) this can
result in incoming packages from multiple dying requests clogging up
the network connection until all the unnecessary activity has died
off, making the next "real" request appear slow as molasses.

[*] but there is a -child option.

> there doesn't seem to be any inherent obstacle to making these work,
> other than the programmer time/interest, of course.

How do you come to this conclusion?  What *would* be an inherent obstacle
for you?

The way keys are handled now during "partial display" uses a completely
different 'switch' block from the normal one (in mainloop).  Adding handling
for more and more keys would grow that into a mini-version of mainloop,
with a lot of code duplicated yet slightly different.  I say that's an
inherent problem.


   Klaus


reply via email to

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