* 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.
We do however need access to it, so provide a pointer. The difference
is that now we can have a *single* wayland instance, but multiple
terminal instances.
Short term, we want to break out the wayland backend from the terminal
struct. Long term, we might want to support multiple windows.
One step towards both the above is separating global wayland objects
from per-window objects.
Create the sub-surface once, at startup. Then, instead of destroying
it when committing/cancelling a search, unmap it (by attaching a NULL
buffer to it).
* match search buffer against scrollback content
* adjust view to ensure matched content is visible
* create selection on a successful match
* finalize selection when user presses enter (to "commit" the search)
* ctrl+r searches for the next match. Needs more work though.
This adds a new state, 'is_searching'. While active, input is
re-directed, and stored in a search buffer. In the future, we'll use
this buffer and search for its content in the scrollback buffer, and
move the view and create a selection on matches.
When rendering in 'is_searching', everything is dimmed. In the future,
we'll render the current search buffer on-top of the dimmed "regular"
terminal output.
