I concur... <applause> Nicely summarized too, Nance... (:
> Flip that and you have the best of both worlds: if n is 0 never
> update. This would be equivalent to "off" in your first suggestion.
> > * if n > 0, update every n lines of output
> And if n is 1, then you'll update every line, which is the current
> behaviour and would be equivalent to "on" in your first suggestion.
> > * if n < 0, update only when the user hits 'return'
> Actually, I'm not sure I see the point of this, but I guess it would
> be nice for slow modem connections particularly.
> > This aproach seems rather confusing, but people would get used
> > to it, I believe.
> I think it's the most pragmatic approach. If it's not overly
> difficult, I'd vote for this; setting the n high (or negative) helps
> slow modem connection; setting it to 0 helps us people whose displays
> are being hosed by the existing behaviour; and setting it to 1 (which
> I guess would be the default, or 0) would give you the current
> behaviour.
I agree... it seems to give the user the best of _all_ worlds, given Ceej's
modification...
> > - Update the number of lines pending only when the output "stops".
> > Definition of "stopping" would be given by the user:
> > '%update_rate n' where n is given in seconds, or 'lily -u n'.
>
> Eh, I'm not so crazy about this. It really only indirectly addresses
> the problems we've seen (slow modems and trashed TTYs), so it's not as
> immediately useful. The one place I can see where this WOULD be useful
> is when doing review, either coming back from detach or just reviewing
> a discussion, so it could conceivably be nice if this suggestion was
> invisibly implemented all the time with n a very small interval of
> time (say half a second). That would prevent huge prompt-update spam
> when reviewing but not be noticable for interactive IO.
Kewl! This is a _great_ idea - update every N lines under normal conditions
but no more frequently than once every Y seconds.... the perfect review-spam
fix... I like this...
> One question: Could/Should the client do something special if the
> --more-- prompt is reached while the user is typing a line? Just a
> thought for debate...
Actually, it would be nice if it it would _not_ insert what I'm typing
into the middle of what's being displayed if I start typing during a
pause in communication between the client and server, but I suspect this
is a non-trivial readline problem (it's also the key reason I advocated
a screen-refresh-capable client...)
Keep up the great work!
-Gord
-- Gordon Lloyd Goldberg <ggold@panix.com>