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 we insert an auto-newline, we must make sure we don't try to move
outside the terminal window.
This can for example happen when a scrolling region have been
configured, and the cursor is **outside** the scrolling
region (i.e. it's in the bottom margin).
Having them as error messages was nice when we where still missing
lots of sequences.
Now we don't anymore, and these just spam stdout as well as syslog
when e.g. cat:ing binary data.
In most states, most 8-bit values are no-ops. This is already handled;
action() recognizes ACTION_NONE as a no-op. Thus, all we need to do is
remove the assertion.
Show 'text' cursor when:
* we have no mouse tracking enabled
* forced selection has been enabled (shift being held down)
* We're *not* scrollback searching
In all other cases, show the 'left_ptr' cursor.
When the user had configured the cursor color, we failed to
invert (reverse) the foreground and background color when the cursor
was on a cell with the 'reverse' attribute set.
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.
But only do this when the font is scalable but not an outline. This is
only true for color bitmap fonts (emoji fonts), and not e.g. regular
bitmap fonts.
When we receive a keyboard_key or pointer_motion event without first
having received a keyboard_enter or pointer_enter event (that being
the "sway bugs" part), we generally don't know _which_ terminal window
the event was intended for.
However, if we only have *one* window open (always the case for a
regular 'foot' process, or when there's a single footclient connected
to a foot server process), then obviously we can "guess" which window
the event was intended for... so do that.
Now, the only time the event is ignored is when we're a server process
with more than one window open (= more than one footclient connected).
