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
Before this patch, foot only applied [scrollback].multiplier on the
normal screen, never the alt screen.
However, scrolling can be done in two ways on the alt screen:
If the application has enabled mouse support, we simply pass on the
mouse scroll events to the application. Here, it makes sense to not
apply the multiplier, and instead let the application choose how much
to scroll for each scroll event.
But, if the application has not enabled mouse support, we can still
scroll by simulating the arrow keys being pressed - alternate
scrolling (private mode 1007).
This is enabled by default in foot (but can be disabled in foot.ini
with the [mouse].alternate-scroll-mode setting).
In this mode, it makes more sense to apply the multiplier. And that’s
what this patch changes - the multiplier is now applied, on the alt
screen, when the application has not enabled mouse support, and
alternate scrolling has been enabled in foot.
Closes#859
If we have an “active” OSC-8 URI, term_print() would correctly replace
an existing URI with the new one.
But, if we don’t have an active URI, an existing URI was not
erased. This can be reproduced with e.g
echo -e '\e]8;;http://foo.bar\e\\foobar\e]8;;\e\\\b\b\b\b\b😀\n'
When going through the cached buffers, we only set buffer->busy on
the *first* re-usable buffer we found.
In some cases, we will find more than one re-usable buffer. In this
case, we select the “youngest” one (i.e the one most recently used, in
the hopes that we can use damage tracking instead of re-rendering the
entire buffer).
If the “current” buffer is younger than the previously detected,
re-usable, buffer, then we unref:ed the previously selected buffer,
and replaced it with the current one.
But, we did not sanitize it. That is, we did not:
* set buffer->busy
* clear its dirty region
* clear its scroll damage
That buffer would eventually get rendered to, and committed to the
compositor. Later, the compositor would free it. And there, in our
buffer_release() callback, we’d assert that buffer->busy was
set. And fail.
Closes#844
When handling “generic” keys (i.e. keys not in the Kitty keymap), we
use the pressed key’s Unicode codepoint as “key” in the kitty CSI.
If we failed to convert the XKB symbol to a Unicode codepoint, we used
to (before this patch), fallback to using the XKB symbol as is.
This can never be correct... and it caused us to emit a meaningless
CSI for XKB_KEY_ISO_Next_Group, which confused e.g. Kakoune.
