Checking for specific strings of length 0 or 1 can be done with e.g.:
if (str[0] == '\0') {...}
if (str[0] == '?' && str[1] == '\0') {...}
Doing it this way instead of using strlen(3) means we avoid the
function call overhead and also avoid scanning through more of the
string than is neceessary.
A compiler could perhaps optimize away calls to strlen(3) when the
result is compared to a small constant, but GCC 11.2 only seems to
actually do this[1] for lengths of 0.
[1]: https://godbolt.org/z/qxoW8qqW6
With fixed increments of 128 bytes, an OSC 52 copy operation could end
up doing thousands or tens of thousands of realloc(3) calls just to
copy a few MB.
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.
OSC 4/104 changes the 256-color palette. We also run a pass over the
visible cells, and update their colors.
This was previously done by comparing the actual color of the cell,
with the “old” color in the palette. If they matched, the cell was
updated.
This meant that cells with an RGB color (i.e. not a palette based
color) was also updated, _if_ its color matched the palette color.
Now that each cell tracks its color *source*, we can ignore all
non-palette based cells.
Note that this still isn’t perfect: if the palette contains multiple
entries with the same color, we’ll end up updating the “wrong” cells.
Closes#678
Each cell now tracks it’s current color source:
* default fg/bg
* base16 fg/bg (maps to *both* the regular and bright colors)
* base256 fg/bg
* RGB
Note that we don’t have enough bits to separate the regular from the
bright colors. These _shouldn’t_ be the same, so we ought to be
fine...
Doing so means the next OSC-8 URL emitted by the client application,
with the same ID, will get a *new* id internally.
Instead, hash the string and use that as ID.
Applications can assign an ID to the URL. This is used to associate
the parts of a split up URL with each other:
╔═ file1 ════╗
║ ╔═ file2 ═══╗
║http://exa║Lorem ipsum║
║le.com ║ dolor sit ║
║ ║amet, conse║
╚══════════║ctetur adip║
╚═══════════╝
In the example above, ‘http://exa’ and ‘le.com’ are part of the same
URL, but by necessity split up into two OSC-8 URLs.
If the application sets the same ID for those two OSC-8 URLs, the
terminal can ensure they are handled as one.
OSC 777 is URxvt’s generic escape to send commands to its perl
extensions. The first parameter is the name of the extension, followed
by its arguments.
OSC 777;notify is a, if not well established, at least a fairly well
known escape sequence to request a (desktop) notification. The syntax
is:
\e]777;notify;<title>;<body>\e\\
Neither title nor body is escaped in any way, meaning they should not
contain a ‘;’.
Foot will split title from body at the *first* ‘;’. Any remaining ‘;’
characters are treated as part of ‘body’.
Instead of adding built-in support for the freedesktop notification
specification (which would require us to link against at least dbus),
add a new config option to foot.ini: ‘notify’.
This option specifies the command to execute when a notification is
received. ‘${title}’ and ‘${body}’ can be used anywhere, in any
combination, and as many times as you want, in any of the command
arguments.
The default value is ‘notify-send -a foot -i foot ${title} ${body}’
Doing so will schedule the renderer “as soon as possible”. I.e we’re
by-passing the regular scheduler, and thus we’re by-passing the user’s
setting of the delayed-render-* timers.
The fact that we’re scheduling “as soon as possible” also means we’re
much more likely to trigger flickering, or color flashes, if the
application is changing colors which are on the screen.
To handle changes to the cursor color(s), use the new
term_damage_cursor() instead of render_refresh().
To handle background color changes, which affect the margins, use the
new term_damage_margins() instead of render_refresh_margins(),
Closes#141
We only updated the grid for OSC 4 - Set color <idx>. But we did *not*
do it for 104 (reset color <idx>), 10 - set default foreground, 11 -
set default background, 110 - reset default foreground, or 111 - reset
default background.
Since we don't have the original palette index in already rendered
cells, we compare the color *value*. If it matches, we assume this was
the color index used, and updates the cell's color.
Note that for performance reasons, we only update the current
grid. This is of course wrong, strictly speaking.
However, it is expected that _Set Color_ is used by full-screen
applications using the alternate grid.
