Similar to the xterm AllowWindowOps option, this is an option to allow or
disallow certain (non-interactive) operations that can be insecure or
exploited.
NOTE: xsettitle() is not guarded by this because st does not support printing
the window title. Else this could be exploitable (arbitrary code execution).
Similar problems have been found in the past in other terminal emulators.
The sequence for base64-encoded clipboard copy is now guarded because it allows
a sequence written to the terminal to manipulate the clipboard of the running
user non-interactively, for example:
printf '\x1b]52;0;ZWNobyBoaQ0=\a'
St uses a very good hack where mouse wheel genereates ^Y and ^E,
that are the same keys that less and vi uses for backward and
fordward scrolling. Scroll, as many terminal emulators, use
shift+Prev/Next for scrolling, but it is also using ^E and ^Y
for scroling, characters that are reserved in the POSIX shell
in emacs mode for end of line and yanking, making scroll unsable
in st.
This patch adds a new hack, making shift+wheel returning the
same sequences than shift+Prev/Next, meaning that scroll or
any other similar program will not be able to differentiate
between them.
st could easily tear/flicker with animation or other unattended
output. This commit eliminates most of the tear/flicker.
Before this commit, the display timing had two "modes":
- Interactively, st was waiting fixed `1000/xfps` ms after forwarding
the kb/mouse event to the application and before drawing.
- Unattended, and specifically with animations, the draw frequency was
throttled to `actionfps`. Animation at a higher rate would throttle
and likely tear, and at lower rates it was tearing big frames
(specifically, when one `read` didn't get a full "frame").
The interactive behavior was decent, but it was impossible to get good
unattended-draw behavior even with carefully chosen configuration.
This commit changes the behavior such that it draws on idle instead of
using fixed latency/frequency. This means that it tries to draw only
when it's very likely that the application has completed its output
(or after some duration without idle), so it mostly succeeds to avoid
tear, flicker, and partial drawing.
The config values minlatency/maxlatency replace xfps/actionfps and
define the range which the algorithm is allowed to wait from the
initial draw-trigger until the actual draw. The range enables the
flexibility to choose when to draw - when least likely to flicker.
It also unifies the interactive and unattended behavior and config
values, which makes the code simpler as well - without sacrificing
latency during interactive use, because typically interactively idle
arrives very quickly, so the wait is typically minlatency.
While it only slighly improves interactive behavior, for animations
and other unattended-drawing it improves greatly, as it effectively
adapts to any [animation] output rate without tearing, throttling,
redundant drawing, or unnecessary delays (sounds impossible, but it
works).
Support for OSC escape sequences 10, 11 and 12 to modify the bg, fg and
cursor colors. I selected entries in the colorname table after the 255
position for defaultfg, defaultbg and defaultcs
Scroll is a program that stores all the lines of its child and be used in st as
a way of implementing scrollback.
This solution is much better than implementing the scrollback in st itself
because having a different program allows to use it in any other program
without doing modifications to those programs.
bakkeby