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).
I.e. what we're effectively doing is *not* repeating modifier
keys.
Besides being the "right" thing to do, this also works around another
Sway 1.2 bug, where being in a focused foot window and then switching
to a vt and back would cause us to be stuck in an endless key repeat
loop that would only stop when unfocusing, focusing back and then
unfocusing once again.
Sway 1.2 has been seen sending keyboard_key() events without first
sending a keyboard_enter() event.
This can be triggered by:
1. start a foot terminal
2. unfocus it (move focus to another window)
3. switch to a vt
4. switch back to sway
5. focus the foot terminal
At this point, Sway will *not* send the keyboard_enter() event, but
instead send a keyboard_key() event.
(furthermore, if you now unfocus the window again, sway will send a
keyboard_leave() event, still without having sent a keyboard_enter()
event).
Sway has _also_ been seen crashing in wl_pointer_motion(). Though this
was in a build without proper debug information, everything points to
a similar issue - i.e. sway is sending a motion event without first
having sent an enter event.
Workaround this by detecting this and logging a warning the first time
it happens. The event is then ignored.
