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...
When we calculate the end coords, we must reset end-col when we reach
the end of the line and bump the end-row.
This fixes an issue where bumping the row once lead to the end row
being bumped for *each* remaining match character.
This shouldn't be necessary, but Sway acts up when the subsurface
exceeds the parent surface (window, in this case) size, and extends
the window size (if floating), leaving it with no content
When we've already found a partial match (but *not* a complete match),
and that match spanned multiple lines, then when we continued with the
next start-column we re-used a know-wrong row pointer.
* search_find_next() searches the scrollback, continuing from the last
match. The assumption is that the search buffer has changed.
* search_update_selection() updates the selection and moves the view
to ensure the selection is visible. Note that it doesn't verify the
selection actually matches the search buffer.
If the user has started a scrollback search and have some matching
text, he can now press ctrl+w to extend that selection (and thus the
search criteria too) to the end of the current word, or to the end of
the next word if currently at a word separating character.
When matching characters, we moved on to next row directly after
matching the last character in a row.
This was wrong since if that last character was the last matching
character, we tried to create a selection that was on the wrong row.
