This fixes an assertion when holding in ctrl+shift+c (copy to
clipboard); subsequent "presses" would set the clipboard serial to 0,
which we would then assert on in the next iteration when we tried to
cancel the previous copy.
When we're shutting down a terminal, we destroy our Wayland window,
and assume that will unmap us.
There are cases when this isn't true (most likely when e.g. a screen
locker is active, and the unmap is being deferred).
Handle by explicitly setting focused to NULL.
This happens on Sway when exiting a screen locker. Or at least that's
when we see the problem; it's unclear if the event occurs when
starting the screen locker, or when exiting it. Or maybe its both.
Anyway, don't try to unfocus a NULL-terminal.
Since fonts are destroyed and removed from the font cache when the
last instance is destroyed, closing the "last" terminal window in
server mode would destroy the fonts, and their glyph caches.
By instantiating the set in main, we ensure the fonts, and the glyph
caches, remain. This makes launching new terminals (much) faster.
Note that in "normal" (non-server) mode, this isn't really necessary,
but also doesn't have any penalty.
This reverts commit 7c2dd93690.
Or repeated pkgbuilds will fail since the first meson call
doesn't *re*configure an already configured build tree, causing us to
build with pgo=use when we should be using pgo=generate.
This reverts commit 739c5cf7f0.
The original commit stated:
Not sure why these were added here; they don't appear to be
needed (we're writing to the client - it's up to the client to echo
stuff, in which case we redraw as usual).
But, client output doesn't cause a scrollback/view reset.
'p' means 'primary', while 's' means 'selection'. Thus, a client can
now request 'selection' clipboard data and will receive it from the
primary selection.
Report us as being VT220, as VT420 causes vttest to send a
DECRQSS. This is a DCS request that we don't implement (there's no DCS
handling *at all* - all DCS strings are ignored).
Should be ok as no one appears to care about this one. Other terminals
report a much lower level (urxvt for example, replies with vt100. We
used to reply with vt102, which also was fine).
Pretend we're a VT420, with a couple of supported features
indicated. Note that I haven't verified we support *everything* that
each features entails - or even what exactly a feature *is* (locator
port?)
In the legacy mouse reporting mode, line and column numbers are
limited to 223 (255-32). In case the current coordinate falls outside
this, simply ignore it (don't report it).
When support was added for DECOM (absolute/relative row addressing), a
small but noticeable (~3.5%) performance regression was introduced.
Try to improve the situation by simplifying the relative-to-absolute
conversion; only the row needs to be transformed.
* It takes a parameter, that indicates the number of tab stops to move
through
* Use the tab stops defined in the tab stops list, not hard coded mod
8 columns.
There were actually two bugs here:
* When checking for a tab stop, make sure the new tab stop is at a
different column. Otherwise you can't tab away from a tab stop.
* When there aren't any tab stops configured, or when we're already
beyond the last tab stop, then tab to the last column (at least I
think that's what we're supposed to do).
