When the compositor is asking us to resize ourselves, take
our (visible) CSD borders into account. This is similar to how we
already take the titlebar size into account.
This fixes an issue where the window size “jumps” when the user starts
an interactive resize, when csd.border-width > 0.
This as been observed in GNOME.
When this option is used, the child process in the new terminal
instance will inherit its environment from the footclient process,
instead of the foot server’s.
Implemented by sending (yet another) dynamic string list as part of
the client -> server setup packet. When the new option is *not* used,
the setup packet is now 2 bytes larger than before.
On the server side, the slave process now uses execvpe() instead of
execvp(). There’s plumbing to propagate a new ‘envp’ argument from
term_init() all the way down to slave_exec(). If ‘envp’ is NULL, we
use ‘environ’ instead (thus matching the old behavior of execvp()).
Closes#1004
The underline cursor is positioned just below regular underlines. A
bug in the positioning logic related to this, sometimes resulted in
the cursor being thinner than what it should be, or even invisible.
Fixes#1005
When matching “untranslated” bindings (by matching the base symbol of
the key, e.g. ctrl+shift+2 in US layout), require that no
non-significant modifiers are active.
This fixes an issue where AltGr was “ignored”, and would cause certain
combinations to match a key binding.
Example: ctrl+altgr+0, on many European layouts matched against the
default ctrl+0 (reset the font size), instead of emitting ^]
To make this work, we now need to filter out “locked”
modifiers (e.g. NumLock and CapsLock). Otherwise having e.g. NumLock
active would prevent *all* untranslated matching to fail.
Closes#983
In non-bracketed paste mode, we translate \n to \r, and \r\n to
\r. The latter matches XTerm, urxvt, alacritty and kitty. The former
matches alacritty and kitty (xterm and urxvt just blindly replaces all
\n occurrences with \r, meaning \r\n is translated to \r\r.
For some reason, we then unconditionally translated all \r back to \n,
regardless of whether bracketed paste was enabled or not. Unsure
why/where this comes from, but it doesn't match any of the other
terminal emulators I tested.
One example where this caused issues is in older versions of nano (at
least up to 2.9).
Closes#980
A foot --server instance would exit with code 0, even on failure, if
the number of currently open terminal instances were 0.
This is because ‘ret’ assumed failure, and then tried to set it to
‘success’ after the even loop had terminated, basted on the server’s
current state.
Fix by:
* set ‘ret’ to success just before entering the event loop
* set ‘ret’ to failure when we detect an FDM failure
* don’t try to second-guess success/failure after having exited the
event loop
Closes#943
Fcft no longer uses wchar_t, but plain uint32_t to represent
codepoints.
Since we do a fair amount of string operations in foot, it still makes
sense to use something that actually _is_ a string (or character),
rather than an array of uint32_t.
For this reason, we switch out all wchar_t usage in foot to
char32_t. We also verify, at compile-time, that char32_t used
UTF-32 (which is what fcft expects).
Unfortunately, there are no string functions for char32_t. To avoid
having to re-implement all wcs*() functions, we add a small wrapper
layer of c32*() functions.
These wrapper functions take char32_t arguments, but then simply call
the corresponding wcs*() function.
For this to work, wcs*() must _also_ be UTF-32 compatible. We can
check for the presence of the __STDC_ISO_10646__ macro. If set,
wchar_t is at least 4 bytes and its internal representation is UTF-32.
FreeBSD does *not* define this macro, because its internal wchar_t
representation depends on the current locale. It _does_ use UTF-32
_if_ the current locale is UTF-8.
Since foot enforces UTF-8, we simply need to check if __FreeBSD__ is
defined.
Other fcft API changes:
* fcft_glyph_rasterize() -> fcft_codepoint_rasterize()
* font.space_advance has been removed
* ‘tags’ have been removed from fcft_grapheme_rasterize()
* ‘fcft_log_init()’ removed
* ‘fcft_init()’ and ‘fcft_fini()’ must be explicitly called
This ensures processes spawned by us (e.g. the shell, new terminal
instances etc) don’t inherit a flawed signal mask, or having signals
unknowingly ignored.
Closes#854
In Sway-1.5, sway waits for configure ACKs from hidden windows when
views are being resized. I.e. if you have e.g. a stacked view, with
one or more windows currently not visible, and you resize the stack,
then sway will emit configure events to all windows, and then wait for
ACKs before rendering the resized view.
The problem with this is that sway also does **not** call frame
callbacks on hidden windows. So if we have rendered one frame, and
thus registered a frame callback, we’ll never render any more frames
until the window becomes visible again. Ergo, if you resize the view
interactively, only the first resize actually happens. After that, all
hidden views are “stuck”, causing ACK timeouts.
We worked around this in foot by preempting the frame
callback. I.e. destroying it, and rendering the frame anyway.
This has fixed in sway-1.6, and thus we can remove the workaround.
In our default mode (roughly equivalent to XTerm’s modifyOtherKeys=1),
alt-tab now emits ESC-tab instead of CSI 27;3;9~.
When modifyOtherKeys=2 is enabled (CSI >4;2m), alt-tab emits the “old”
CSI 27 escape.
This better matches XTerm’s behavior.
Note that other alt-tab combos are ambiguous in XTerm, and thus they
are left unchanged here (i.e. we keep emitting CSI 27 escapes for
them).
Closes#900
POSIX.1-2008 has marked gettimeofday(2) as obsolete, recommending the
use of clock_gettime(2) instead.
CLOCK_MONOTONIC has been used instead of CLOCK_REALTIME because it is
unaffected by manual changes in the system clock. This makes it better
for our purposes, namely, measuring the difference between two points in
time.
tv_sec has been casted to long in most places since POSIX does not
define the actual type of time_t.
This patch adds support for DECRQSS (request Selection or Setting),
for the following sub-queries:
* DECSTBM Set Top and Bottom Margins
* SGR Set Graphic Rendition
* DECSCUSR Set Cursor Style
Closes#798
As described in #883, creating a block selection (with ctrl+BTN_LEFT),
then *quickly* (within 300ms from) creating a new one, will, in fact,
_not_ create a new block selection, but a ‘select-word-whitespace’
selection (ctrl+BTN_LEFT-2).
A similar effect can be seen with plain selections (BTN_LEFT). Click
and drag to make a selection, but *release*, and make a new selection
within 300ms from the initial button press, and the new selection is
suddenly a word-based selection.
This happens because triggering a binding does *not* reset the button
click counter.
So, shouldn’t we just do that?
No, because we rely on this behavior to handle single-, double- and
triple-click actions. If we were to reset the button click handler,
then we’d have to instead delay triggering the first action with
300ms, which would make things appear laggy. If we don’t do this, it
would be impossible to double- and triple-click, since the
single-click action would keep resetting the click counter.
This patch takes a slightly different approach; we reset the click
counter when the mouse has moved “too much”. For now, “too much” is
when the cursor has moved to a different cell.
This way, single-, double- and triple-clicks continue to work as
before. But, creating actual selections, and then quickly releasing
and starting a new selection produces the expected results.
Closes#883
