This fixes an issue where a "forced" selection (shift being pressed
while slave is tracking mouse events) would not finalize if the user
released shift *before* releasing the mouse button.
Previously when updating a selection, we would unmark *all* cells in
the old selection, and then mark all cells in the new selection.
This caused *all* cells to be dirtied and thus re-rendered.
Avoid this, by adding a temporary state to the cells' selected state.
Before unmarking the old selection, pre-mark the new selection using a
temporary state.
When unmarking the old selection, ignore cells in this temporary state.
When marking the new selection, ignore cells in this temporary
state (except clearing the temporary state).
When we extract text, we may insert '\n' at the end of each line (or
last column of selection, for block selections).
These newlines doesn't occupy any physical cells, and thus we
must **make** room for them in the extraction buffer.
When extracting text from the selection, we lost the first column on
all rows but the first.
This is because the algorithm changed slightly when we moved to
foreach_selection(); the end-of-line detection is now done on the
first column of the new line, instead of the last column on the
previous line.
Instead of having the renderer calculate, for each cell, whether that
cell is currently selected or not, make selection_update() mark/unmark
the selected cells.
The renderer now only has to look at the cells' 'selected'
attribute. This makes the renderer both smaller and faster.
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).
When this returns true, it means we have keyboard focus and are
grabbing the mouse (for e.g. selections), regardless of whether the
client has enabled mouse tracking or not.
Up the requirements for enabling "forced" selection (that is, allowing
selections even though mouse tracking has been disabled).
* Require keyboard focus (if we don't have it, then the shift-key
isn't is for us)
* Don't just require shift being pressed, but that all other modifiers
are *not* pressed.
When trying to write (to e.g. the slave, or to a clipboard receiver),
we first try to send the data synchronously, and only if that fails do
we switch to asynchronous mode.
However, the first synchronous may (in fact, is likely to) succeed
partially.
This callback is *always* called, including when there has been an
error.
This is in preparation for making text_from_{clipboard,primary}
asynchronous.
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.
If we scroll enough, we'll eventually end up wrapping around the
entire scrollback buffer. At this point, a selection is no longer
valid, so cancel it.
Note: this was very obvious when scrolling in the alt screen, since
its scrollback buffer is what you see on the screen (i.e. it has no
scrollback).
