This is used in the wild by systemd systemctl for example and st
misinterpreted it as "blink", because it didn't know "58", then saw "5"
as "blink", and then didn't know "245".
This should print "foo" as normal text:
printf '\e[58:5:245mfoo\n'
printf '\e[58:2:50💯200mfoo\n'
Ref.
https://git.suckless.org/st/commit/f114bcedd113017d907aad32031db92c050f4bf3.html
The kitty keyboard protocol docs recommend CSI ? u to query support for
that protocol, see https://sw.kovidgoyal.net/kitty/keyboard-protocol/
For better or worse, fish shell uses this query to work around bugs
in other terminals triggered by requesting that protocol via CSI = 5 u.
Unfortunately, st interprets CSI ? u as DECRC (restore cursor
position). reproduce with 'printf "\x1b[?u"; cat'.
fish could work around this by switching to the alternate screen
before running this query; but that might cause tearing on terminals
that don't support Synchronized Output. I'm not sure.
In the meantime, let's correct our parser.
This adds a redundant else-after-return, for consistency with the
surrounding code.
ref. https://git.suckless.org/st/commit/98610fcd37f655d44586323dc86c1d013c2798ce.html
Signed-off-by: Laurent Cheylus <foxy@free.fr>
Some old clipboard managers, such as greenclip and parcellite,
constantly poll applications with SelectionRequest events, which breaks
the internal timer and blinking cursor. This fix prevents these events
from causing any disruption.
Fixes#172
* osc7: initial patch implementation
Closes#153
* osc7: avoid redundant use of realpath()
* osc7: fix styling
* Changing position of the OSC7_PATCH toggle in patches.def.h
---------
Co-authored-by: Bakkeby <bakkeby@gmail.com>
This fixes the current implementation, which does not delete an image if
an application first erases the image and then spawns a new transparent
image in its place. The reason it didn't work before was because the two
operations were handled at different stages in the rendering pipeline.
Old images are automatically deleted if a new image is spawned over
them. This prevents them from piling up and choking the terminal when
viewing animated gifs.
Now if you use the latest version of Chafa to view the gifs, it
will set the transparency attribute (P2=1) to all sixel images
regardless of whether they are transparent or not. This prevents the
auto-delete from working because if the image is transparent, we can't
delete any images behind it.
The solution is that since Chafa fills the animation frames with an
opaque black background color, we treat the images as non-transparent if
they don't have any transparent pixels. This keeps the auto-delete
running with the new Chafa.
Although the solution works now, it may not be a long-term solution.
