BTN_BACK and BTN_FORWARD are separate buttons. The scroll wheel don't
have any button mappings in libinput/wayland, so make up our own
defines.
This allows us to map them in mouse bindings.
Also expose BTN_WHEEL_{LEFT,RIGHT}. These were already defined, and
used, internally, to handle wheel tilt events. With this, they can
also be used in mouse bindings.
Finally, fix encoding used for BTN_{BACK,FORWARD} when sending mouse
button events to the client application. Before this, they were mapped
to buttons 4/5. But, button 4/5 are for the scroll wheel, and as
mentioned above, BTN_{BACK,FORWARD} are not the same as scroll wheel
"buttons".
Closes#1763
When changing part of the color palette, through either OSC-4, or
OSC-10 and OSC-11 (and the corresponding reset OSCs: 104, 110 and
111), only dirty affected cells.
We've always done this, but only for OSC-4.
This patch breaks out that logic, and extends it to handle default
fg/bg too.
It also fixes a bug where cells with colored underlines were not
dirtied if the underline was the only part of the cell that was
affected by a OSC-4 change.
The documentation of these sequences are vague and lacking, as is
often the case with XTerm invented control sequences.
I've tried to replicate what XTerm does (as of xterm-392).
The stack represents *stashed/stored* palettes. The currently active
palette is *not* stored on the stack.
The stack is dynamically allocated, and starts out with zero elements.
Now, XTerm has a somewhat weird definition of "pushing" and "popping"
in this context, and the documentation is somewhat misleading.
What a push does is this: it stores the current palette to the stack
at the specified slot. If the specified slot number (Pm) is 0, the
slot used is the current slot index incremented by 1.
The "current" slot index is then set to the specified slot (which is
current slot + 1 if Pm == 0).
Thus, "push" (i.e. when Pm == 0 is used) means store to the "next"
slot. This is true even if the current slot index points into the
middle of stack.
Pop works in a similar way. The palette is restored from the specified
slot index. If the specified slot number is 0, we use the current slot
index.
The "current" slot index is then set to the specified slot -
1 (current slot - 1 if Pm == 0).
XTREPORTCOLORS return the current slot index, and the number of
palettes stored on the stack, on the format
CSI ? <slot index> ; <palette count> # Q
When XTPUSHCOLORS grows the stack with more than one element (i.e. via
a 'CSI N # P' sequence), make sure *all* new slots are initialized (to
the current color palette). This avoids uninitialized slots, that
could then be popped with XTPOPCOLORS.
Closes#856
10/11/17/19 were already merged, so this patch just stops special
casing 12 (cursor color).
In preparation for XTPUSHCOLORS/XTPOPCOLORS, the cursor colors are
moved from their own struct, into the 'colors' struct.
Also fix a bug where OSC 17/19 queries returned OSC-11 data.
Reproducer:
CFLAGS='-Og -g' meson setup --buildtype=debug bld
ninja -C bld
Error message:
../render.c: In function ‘draw_styled_underline’:
../render.c:490:19: error: ‘y_ofs’ may be used uninitialized
[-Werror=maybe-uninitialized]
490 | const int top = y + y_ofs;
| ^~~
../render.c:405:9: note: ‘y_ofs’ was declared here
405 | int y_ofs;
| ^~~~~
Before this patch, we asserted both the cursor foreground, and
background colors had been set. This is true in most cases; the config
system enforces it.
It is however possible to set only the cursor background color, while
leaving the foreground (text) color unset:
* Use a foot config that does *not* configure the cursor colors. This
means foot will invert the default fg/bg colors when rendering the
cursor.
* Override the cursor color using an OSC-12 sequence. OSC-12 only sets
the background color of the cursor, and there is no other OSC sequence
to set the cursor's text color.
To handle this, remove the assertion, and simply split the logic for
the cursor backgound and foreground colors:
* Use the configured background color if set (either through config or
OSC-12), otherwise use the default foreground color.
* Use the configured foreground color if set (through config),
otherwise use the default background color.
Try to make the 'dotted' style appear more even, and less like each
cell is rendered separately (even though they are).
Algorithm:
Each dot is a square; it's sides are that of the font's line
thickness.
The spacing (gaps) between the dots is initially the same width as the
dots themselves.
This means the number of dots per cell is the cell width divided by
the dots' length/width, divided by two.
At this point, there may be "left-over" pixels.I.e. the widths of the
dots and the gaps between them may not add up to the width of the
cell.
These pixels are evenly (as possible) across the gaps.
There are still visual inaccuracies at small font sizes. This is
impossible to fix without changing the way underlines are rendered, to
render an entire line in one go. This is not something we want to do,
since it'll make styled underlines, for a specific cell/character,
look differently, depending on the surrounding context.
This union is identical to row_range_data, except the URI char pointer
is const. Let's ignore that, and re-use row_range_data, casting the
URI pointer when necessary.
Also remove uri_range_insert() and curly_range_insert(), and use the
generic version of range_insert() everywhere.
grid_row_uri_range_put() and grid_row_curly_range_put() now share the
same base logic.
Range specific data is passed through a union, and range specific
checks are done through switched functions.
The things affecting which ASCII printer we use have grown...
Instead of checking everything inside term_update_ascii_printer(), use
a bitfield.
Anything affecting the printer used, must now set a bit in this
bitfield. This makes term_update_ascii_printer() much faster, since
all it needs to do is check if the bitfield is zero or not.
Only clear OSC-8 hyperlinks at the target columns if we don't have an
active OSC-8 URI. This corresponds to normal VT attributes; the
currently active attributes are set, and all others are cleared.
Handle styled underlines in the same way
When doing an interactive resize, we create a small grid copy of the
current viewport, and then do a non-reflow resize.
When the interactive resize is done, we do a proper reflow. This is
for performance reasons.
When creating the viewport copy, we also need to copy the styled
underlines. Otherwise, styled underlines will be rendered as plain
underlines *while resizing*.
This was originally contributed by @kraftwerk28 in
https://codeberg.org/dnkl/foot/pulls/1099
Here, we re-use the rendering logic only, as attribute tracking has
been completely rewritten.
This is work in progress, and fairly untested.
This adds initial tracking of styled underlines. Setting attributes
seems to work (both color and underline style). Grid reflow has *not*
been tested.
When rendering, style is currently ignored (all styles are rendered as
a plain, legacy underline).
Color however, *is* applied.
Right now (Unicode 15.1), all valid variation sequences consist of a
single Unicode codepoint (followed by either VS-15 or VS-16).
Don't assume this is the case.
We don't actually handle longer sequences. But now we at least catch
such escapes, and error out.
