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
The compositor may offer version 4, while we’re still linked against
an old libwayland that does not implement version 4.
While we properly #ifdef the callbacks from version 4, we were still
requesting version 4 (if offered by the compositor), even when
compiled against a too old libwayland.
Closes#876
Our getopt_long() based argument parser would (correctly) break out of
the while loop immediately. However, we would then proceed and
decrement ‘argc’ by 1, resulting in it being -1.
This was then passed to the terminal constructor, which passed it on
to the client application fork+exec logic. That finally resulted in an
exec(3) failure:
err: slave.c:339: SHELL=/bin/zsh: failed to execute: No such file or directory
err: fdm.c:215: no such FD: 7
info: main.c:604: goodbye
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 using indexed colors (i.e. SGR 30/40/90/100), store the index
into the cell’s fg/bg attributes, not the actual color value.
This has a couple of consequences:
Color table lookup is now done when rendering. This means a rendered
cell will always reflect the *current* color table, not the color
table that was in use when the cell was printed to.
This simplifies the OSC-4/104 logic, since we no longer need to update
the grid - we just have to damage it to trigger rendering.
Furthermore, this change simplifies the VT parsing, since we no longer
need to do any memory loads (except loading the SGR parameter values),
only writes.
