The main problem is knowing:
* The correct *cell* (to be able to render the *content* when erasing
the old cursor)
* Whether the cursor has moved (to determine whether to stop the
rendering loop or not)
* Where on the *screen* the cursor is/was (since the terminal may be
partly scrolled back)
This patch stores three static variables:
* last_cursor is used to compare against current cursor to see if the
cursor has moved or not
* last_cursor_on_screen is the actual screen coordinates the cursor
was rendered at (typically the same as last_cursor, but may be
offset by the view)
* last_cursor_cell is a pointer to the cell to render
The default is to reverse the foreground/background colors in the cell
with the cursor.
But, if the user configures a specific set of cursor colors, those
will always be used, regardless of other cell attributes (dim, reverse
etc).
The cursor color is specified as two color values, 'text' and
'cursor'.
The block cursor uses the 'cursor' color as background, and the 'text'
color for the glyph.
All other cursor styles uses the 'cursor' color for the cursor, but
uses the cell's foreground color for the glyph (meaning,
dim/reverse/etc applies).
Use our own escape sequence for the 'flash' terminfo entry.
Implemented by arming a timer FD and setting a boolean that indicates
we're currently "flashing".
The renderer draws a semi-transparent yellowish layer over the entire
window when "flashing" is active.
To avoid having to re-generate glyphs, cache the glyphs.
For now, we only cache ASCII characters, as this allows us to lookup
the cache by simply indexing with the character (into a 256-entry
array).
* 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
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.
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...
The grid is now represented with an array of row *pointers*. Each row
contains an array of cells (the row's columns).
The main point of having row pointers is we can now move rows around
almost for free.
This is useful when scrolling with scroll margins for example, where
we previously had to copy the lines in the margins. Now it's just a
matter of swapping two pointers.
