It’s ok to let the receiving end handle formatting C0 control
characters in bracketed paste mode.
In fact, we *must* let them through. Otherwise it is impossible to
paste e.g. tabs into editors and similar applications.
When ‘selection-target’ is set to ‘none’, selecting text does not copy
the text to _any_ clipboard.
This patch also refactors the value parsing to be data driven.
In addition to letting the FDM do the low-level signal watching, this
patch also fixes a bug; multiple SIGCHLDs, be it delivered either through a
signal, or via a signalfd, can be coalesced, like all signals.
This means we need to loop on waitpid() with WNOHANG until there are
no more processes to reap.
This in turn requires a small change to the way reaper callbacks are
implemented.
Previously, the callback was allowed to do the wait(). This was
signalled back to the reaper through the callback’s return value.
Now, since we’ve already wait():ed, the process’ exit status is passed
as an argument to the reaper callback.
The callback for the client application has been updated accordingly;
it sets a flag in the terminal struct, telling term_destroy() that the
process has already been wait():ed on, and also stores the exit
status.
Add fdm_signal_add() and fdm_signal_del(). Signals added to the fdm
will be monitored, and the provided callback called as “soon as
possible” from the main context (i.e not from the signal handler
context).
Monitored signals are *blocked* by default. We use epoll_pwait() to
unblock them while we’re polling. This allows us to do race-free
signal detection.
We use a single handler for all monitored signals; the handler simply
updates the signal’s slot in a global array (sized to fit SIGRTMAX
signals).
When epoll_pwait() returns EINTR, we loop the global array. The
callback associated with each signal that fired is called.
To reproduce issue:
- Launch an IME from inside foot
- Type in some preedit text
- Use Ctrl-C to close the IME
- IME text stays in terminal until focus is changed
Before passing the pasted text to the decoder, we now replace \r\n,
and \n, with \r.
The URI decoder was looking for a \n, which meant we failed to split
up the list and instead pasted a single “multi-line” URI.
We failed to convert the byte-indices to cell indices, resulting in a
box cursor covering the entire pre-edit string.
Note that in addition to fixing the translation from byte index to
cell index, the rendered had to be updated to dirty one extra cell
from the original grid.
Without this, we left trailing cursors behind us when the user deleted
text from the pre-edit string.
When rendering the search input box, do the same ad-hoc workaround for
combining characters with a positive x-offset as we do when rendering
normal grid cells.
In this case, we don’t *know* when we’re dealing with combining
characters. But we can detect zero-width characters. For these, check
their glyph’s x-offset. If positive, adjust it like we do when
rendering combining glyphs in the main grid, to ensure the glyph is
positioned over the _previous_ character, not the next.
These two buttons were encoded using the *exact* same numbers as
button 4 and 5 (scroll wheel up/down), making it impossible to
distinguish them.
The relevant section from XTerm’s control sequences documentation is:
Some wheel mice can send additional button events, e.g., by tilting the
scroll wheel left and right.
Additional buttons are encoded like the wheel mice,
o by adding 64 (for buttons 6 and 7), or
o by adding 128 (for buttons 8 through 11).
The freebsd/latest image is still FreeBSD-12, with clang-8. It
generate false positive warnings:
../../foot/search.c:357:21: error: suggest braces around initialization of subobject [-Werror,-Wmissing-braces]
mbstate_t ps = {0};
This fixes an out-of-range comparison in 32-bit builds:
client.c:289:19: error: result of comparison of constant 4294967296 with expression of type 'size_t' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
if (total_len >= 1llu << (8 * sizeof(uint32_t)) ||
~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ncurses on FreeBSD still uses termcap(5) while foot works fine with
xterm-256color sans status line and visible bell. Having more than
one ncurses version installed may break other applications.
Document -Dterminfo=false uses --term=xterm-256color by default
Base compiler on BSDs doesn't look where packages are installed to
avoid tainting build environment. When system fcft is installed to
the same prefix as wayland-client it passes CFLAGS that satisfy both
but when using subprojects/fcft there's a build error.
xdg-shell.c:33:10: fatal error: 'wayland-util.h' file not found
xdg-decoration-unstable-v1.c:28:10: fatal error: 'wayland-util.h' file not found
xdg-output-unstable-v1.c:28:10: fatal error: 'wayland-util.h' file not found
presentation-time.c:28:10: fatal error: 'wayland-util.h' file not found
primary-selection-unstable-v1.c:28:10: fatal error: 'wayland-util.h' file not found
text-input-unstable-v3.c:33:10: fatal error: 'wayland-util.h' file not found
In file included from ../../foot/grid.c:1:
In file included from ../../foot/grid.h:5:
In file included from ../../foot/terminal.h:19:
../../foot/wayland.h:8:10: fatal error: 'wayland-client.h' file not found
In file included from ../../foot/selection.c:1:
../../foot/selection.h:4:10: fatal error: 'wayland-client.h' file not found
