my previous detection for continueous input was completely wrong.
Now we just assume that anything coming in from Stdin could be infinite.
Additionally, in case we think it's infinite but we were actually able
to close the Reader stream, we consider it non-infinite after that
point.
... by punting the problem when the input is an infinite stream.
This commit fixes the blocking, but the subsequent queries don't seem
to be properly running
refs #494
In order to serve the user filtered results as fast as possible,
we start reading from Source as soon as we have acquired a few lines
from STDIN or file.
So in case of #389, we started to process the source while we
are still reading from STDIN. But that means our buffer is not
quite ready with all of the input from STDIN.
Meanwhile, the filtering thinks it's done when we reach end of input
mark prematurely, and it never resumed reading. This is why we have
less lines than we should.
Now, in order to fix this, we need to process as much as we have, and
then come back to see if we have more. We do this by looping until
the setupDone channel is closed, and we have exhaused our buffer.
This fixes#389, but it also shows that the processing is a little
different when we run the filter for the first, and subsuquent
executions. Apparently the next execution takes a little bit longer
to *draw* (note: I have not checked if it's the filtering that's slow,
or that simply if the draw timings are off)
I should've done this a long time ago, but what's done is done.
There was one more omission between v0.3.x and v0.4.x, which is
buffer-size :/
At least I'm glad I got this out of the way.
