Add a separate section for bell configuration, with a bell-specific
command option and a setting to allow that command to run without regard
to keyboard focus (for those of us who enjoy being beeped at at all
times, for example). The actions are also no longer mutually exclusive;
this is primarily anticipating urgency support which cannot be
replicated outside the process (in server mode anyway) and would thus be
complementary to any notification or arbitrary command.
* less highlighting
* it’s ‘virtual *address space*’
* mention it’s only supported on Linux
* mention it’s only supported on 64-bit archs (but not necessarily x86_64)
In all other cases, alpha is disabled. This includes:
* Palette- or RGB-colors matching the default background color
* When any kind of reverse video is enabled (e.g. DECSCNM, or ANSI
reverse)
* foot exits with -26/230
* footclient exits with -36/220
This is to give each application a range of exit codes. Currently
unused, but we may want to change this in the future.
Normally, foot and footclient uses the exit code from the client
application (i.e. the shell).
However, foot (or footclient) itself may fail to run; if run outside
of a Wayland session, or no fonts are installed, or the client
application/shell cannot be found (“foot lsdjfldsjf”) etc.
Up until now, there has been no way to differentiate these kind of
failures from the client application exiting with code 1.
This patch changes foot’s failure exit code to -27/229, and
footclient’s to -28/228. Note that footclient will exit with foot’s
-27/229 if footclient ran successfully, but the foot server failed to
instantiate a new window.
Closes#466.
All of these include wayland.h (either directly, or indirectly), which
pulls in xkbcommon.h.
Reported by swayyyy on IRC:
FAILED: libvtlib.a.p/dcs.c.o
In file included from ../../terminal.h:19,
from ../../dcs.h:4,
from ../../dcs.c:1:
../../wayland.h:9:10: fatal error: xkbcommon/xkbcommon.h: No such file or directory
9 | #include <xkbcommon/xkbcommon.h>
| ^
* Rename cursor.style value ‘bar’ to ‘beam’. ‘bar’ remains recognized,
but should eventually be deprecated and then removed.
* Add ‘cursor.beam-thickness’ option, a pt-or-px value specifying the
thickness of the beam cursor. Defaults to 1.5pt.
* Rename (and export) pt_or_px_as_pixels() to
term_pt_or_px_as_pixels()
* Change term_pt_or_px_as_pixels() to round point values instead of
truncating them.
When rendering a selected/highlighted cell where the foreground and
background colors are the same, invert the background color to make
the selected text legible.
Closes#455
This is needed when fcft/tllist are built as subprojects, since then
we must ensure their unit tests are executed, or we’ll get “profile
count data file not found” errors.
If width/height (that is, the *pixel* values) are 0, that means we are
early (or that foot is slow) - we’ve managed to reach this point
before the foot window has been mapped.
Or rather, before foot has loaded the primary fonts and calculated the
cell geometry. But that, and the initial mapping of the window is
tightly coupled.
To handle this case, detect when width or height is 0, an then wait
for SIGWINCH before trying again.
When randomizing the sixel width and height, use width/height + 1 in
the call to randrange(). This ensures the width/height is never 0, and
that the maximum width/height is half the window size, not slightly
less than that.
When ‘bold-text-in-bright’ is set ‘to palette-based’, colors matching
one of the 8 regular palette colors are brightened by using the
corresponding bright palette color.
Other colors, or all colors if ‘bold-text-in-bright’ is set to
‘yes|true’, are brightened by increasing the luminance.
We have no guarantee that sub-surfaces extending outside the window
geometry are rendered correctly (if at all).
For example, both Sway and River will render the window border on top
of the sub-surface.
Future versions of Sway may clip the sub-surface.
Since jump-labels are positioned slightly above, and to the left of
the URLs first character, having a label on either the top row, or on
the first column, will likely position it outside the window. This is
handled by simply setting x/y to 0 (or, to -margin, since the label
coordinate is later offsetted with the window margins).
Second, if the label is very long, it may extend outside the
window. This is very unusual for labels only showing the key, and not
the URL itself, but could happen in this case too, if e.g. the user
has configured double-width key characters.
This is handled by calculating its maximum width, and then truncating
the label.
Although very unlikely, it is possible for a label to also extend
outside the window’s vertical size. This could happen for very small
font sizes, where the label’s own margins are large, relative to the
font size. This case is currently not handled.
Closes#443
