Is that really necessary? if your connection can afford 0.5 second
between updates, can it not afford as easly 0 seconds? I mean, sure,
fractions may be nice, but I dont really see them as useful myself.
A second seems to a small enough quanta to me.
> - Important: There -has- to be a way to -disable- lines-pending, as
> has been discussed before. Given the structure of your suggestion,
> I'd suggest %upd_freq -1. Then:
Hm. AT THE MOMENT (in the development area) there is a command-line
switch to use a 'fixed prompt'. It hasn't been tested thoroughly,
granted, but it seems to be doing its job. That setting overrides
every other paging setting (at the moment). The only thing is does
is tha the moment your screen is full and you recieve a new line, it
prints '--More--' with no indication of the number of lines pending.
If there is demand, this will make it to the release. If it seems like
a better idea to use %upd_freq -1 for this, well, it's not very nice, but
we can do that too. At the moment, though, there is no way to change
to/from fixed promt on the fly.
> Other than that, this sounds fine, assuming you can do it.. :)
The above, I can do.
Problem now is I'm trying to accomodate Deven's request that after the
server has been idle for the number of seconds given in %upd_freq,
the prompt be updated, witht he wording "--More--(x lines pending)".
At that point, we know exactly how many lines we have pending. The
next time the server sends anything, we revert to the "at least x
lines pending".
He sent in the patch for the main look (Arround the select() call),
but I still have to re-write a whole bunch of stuff to fit it in.
Is he the only person who wants this? The reasoning for it is that
say I'm reviewing a discussion... I recieved all the review, and I'm
going through it. Before reading it all, I do a /who everyone. My
line count wont be correct until I hit return again, or the server
sends more data.
Do other people think this is necessary? or at least even useful?
it IS a hassle for me to do it, even with Deven's code...
I personally would rather be fixing %export.
Nancy
--
Nancy Deschenes
nancyd@alcor.concordia.ca