* Start selection on mouse button down
* Update selection on motion
* Button release cancels selection if there were no motion after start
* Renderer detects cells inside the selection and inverts their colors
Since newly scrolled in lines will be erased, we want them in the
cache.
So, allocate and prefetch new lines, then repair non-scrolling
regions (to give the prefetch time to actually fetch the
data). Finally, erase the newly scrolled in lines.
This also fixes a bug where the fixup for the non-scrolling regions
could crash on an unallocated row (we were accessing rows that would
be, but hadn't yet been, scrolled in).
The row array may now contain NULL pointers. This means the
corresponding row hasn't yet been allocated and initialized.
On a resize, we explicitly allocate the visible rows.
Uninitialized rows are then allocated the first time they are
referenced.
linefeed moves cursor down one row (columns stays the same), or, if
the cursor is at the last row, scrolls up one row.
reverse_index does the opposite; it moves the cursor *up* one row, or,
if the cursor is at the top row, scrolls *down* one row.
Can scroll up and down, and stops when the beginning/end of history is
reached.
However, it probably breaks when the entire scrollback buffer has been
filled - we need to detect when the view has wrapped around to the
current terminal offset.
The detection of when we've reached the bottom of the history is also
flawed, and only works when we overshoot the bottom with at least a
page.
Resizing the windows while in a view most likely doesn't work.
The view will not detect a wrapped around scrollback buffer. I.e. if
the user has scrolled back, and is stationary at a view, but there is
still output being produced. Then eventually the scrollback buffer
will wrap around. In this case, the correct thing to do is make the
view start following the beginning of the history. Right now it
doesn't, meaning once the scrollback buffer wraps around, you'll start
seeing command output...
