Instead of trying to figure out if we had to render
something (i.e. something in the grid was dirty), and using that to
determine whether to post a callback or not, we now let
render_refresh() set a flag indication we need to render another
frame.
This simplifies render_grid(), which now _always_ renders, and pushes
it to the compositor.
The callback handler checks the pending flag and simply doesn't call
render_grid() when there's no more pending state to render.
This ends up reducing the number of wakeups when e.g. having a
blinking cursor.
Normally we don't dirty the cell on cursor movement. But, since a
blinking cursor isn't a cursor that has moved, our normal cursor
rendering wont work.
Dirty the cursor cell to force a redraw of it.
Blinking can be enabled either by setting the cursor style with
CSI Ps SP q
and selecting a blinking style.
Or, with 'CSI ? 12 h'
Note that both affect the same internal state. I.e. you can disable
blinking with CSI ? 12l after having selected a blinking cursor
style. This is consistent with XTerm behavior.
This behavior is debatable, but helps in error handling where we're
removing a bunch of descriptors where not all of them have been added
to the FDM yet.
Instead of first memmoving, possibly lots of data lots of times, the
received buffer, and _then_ calling the callback, simply call the
callback multiple times, and just skip the \r character(s).
XTerm seems to ignore these when in UTF-8 mode. Since we _only_
support UTF-8, we don't need to recognize these control characters at
all.
However, it may be good to have them here for reference. So add them,
but commented out, along with their corresponding 7-bit
versions (which we _do_ recognize and implement).
When splitting the font configuration into multiple font
specifications, we now trim leading spaces.
This makes no actual difference; fontconfig matched the fonts just
fine anyway, but this looks better in the logs.
In most cases (i.e. when there's only a single output/monitor), this
will be *the* DPI value.
In other cases, well...
The _right_ thing to do is track the outputs our window is actually
mapped on, and re-instantiate fonts depending on the current output's
DPI. But that's for the future...
