🚀 go-pugleaf

In article <856807122snz@wash.demon.co.uk>
           john@wash.demon.co.uk "John Washington" writes:

> [...]
> It seems as if the ftp (or http) process is actually
> running, so the screen output is being queued, but
> unless there's a '\n' in the output, the corresponding
> display task is not painting the screen.
> [...] 
> Any users of the http version worried if I change that
> damn hash code to a bytecount???  (I like to see a number
> updated every 1K or so, overwriting on the same line,
> instead of those interminable hashes).

IF the queued screen output could be instructed to paint the
screen on receiving a '\n' OR '\r' then adding a bytecount
ending with a '\r' would solve the problem.

IMHO it is easier to interpret a bytecount than (a few lines
of) hashes, so why not change the hashes in ftp to a bytecount
with '\r' too?

One more thought on forcing a screen paint: a very looong time
ago I had a similar problem with dotmatrix printers: those
printers would queue an output line until a '\r' or '\n' was
received but also the line was printed on receiving a backspace
'\010'. Perhaps that is the trick to force a screen update:
write "\010##" rather than a single '#'?

--Peter Fokker