> There are at least 3 ways to deal with this:
> - user settable option: update the prompt always or never
> update the prompt.
This would be fine with me, but see below.
> - Update the prompt only every 'n' lines.
> * if n is 0, update all the time
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
> - 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.
But if that's not possible or too much work to be worth it, I'd be
perfectly happy with my slightly-modified suggestion 2.
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...
aka Chris Hillery