Column: 0 can show `width` columns.
Thus if lines have `num` columns, we should limit scroll to Column: `num - width`.
Otherwise screen is blacked out when we unlimitedly do ScrollRight.
This is required because we need to make sure we know termbox
has been initialized before attempting to make another drawing
operation.
Notably, without proper termbox initialization, screen.Size() returns a
bogus value, and we miss the line location where we left off to execute
the external command specified by --exec
We should wait to initialize the screen until we have something
coming in from the source: otherwise multiple peograms chained via
pipes would compete for the same terminal resource, and things may
go southward.
But then there are components that rely on the screen being intialized,
so we let them wait as well.
--exec is a new, and far better tool to execute external commands
from peco results. It is invoked when `Finish` action is called,
and pipes selected line(s) to the specified command. If there were
saved lines, every saved line plus the currently selected line is
piped to the command. Otherwise, only the currently selected line
is piped.
When the command exits, execution goes back to peco, where you can
keep doing incremental searches, and again execute external commands.
When you are done, you are expected to exit out of peco using
the `Cancel` action
This makes sure that termbox does not inadvertantly steal our
commands while executing external commands, and also makes sure
we explicitly reset the screen.
Also, make sure we use a temporary selection.
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)
