my custom st build https://git.aidengall.xyz/st.git/atom?h=master 2024-03-18T04:07:13Z 2024-03-18T04:07:13Z Aiden Gall aiden@aidengall.xyz 2024-03-18T04:07:13Z urn:sha1:ff28dfbb3f69fc94f536bb09d8be8d026ba6560f 2024-03-17T13:42:44Z Hiltjo Posthuma hiltjo@codemadness.org 2024-03-17T13:42:44Z urn:sha1:f20e169a20f3ee761f7e09714f1d4c10916cf4c6 2023-11-16T15:32:18Z Aiden Gall aiden@aidengall.xyz 2023-11-16T15:28:59Z urn:sha1:7786188a45318f1bcac232d1615ffb8103c80677 2023-11-16T03:24:32Z Aiden Gall aiden@aidengall.xyz 2023-11-16T03:19:37Z urn:sha1:425fceb39d64b88dc3fc4c6715ccef64ad4a0897 2023-11-16T02:35:15Z Aiden Gall aiden@aidengall.xyz 2023-11-16T02:35:15Z urn:sha1:0fa2f8bfe053c36de873a23a1e54f2ad7eca097a 2023-11-16T02:10:50Z Aiden Gall aiden@aidengall.xyz 2023-11-16T02:10:50Z urn:sha1:bd6f16f5e52d51de7fb633a91b84e685aa885025 2021-12-26T17:57:44Z Raheman Vaiya r.vaiya@gmail.com 2021-12-26T17:57:04Z urn:sha1:8e310303903792c010d03c046ba75f8b18f7d3a7 2020-05-30T20:06:15Z Hiltjo Posthuma hiltjo@codemadness.org 2020-05-30T19:56:18Z urn:sha1:a2a704492b9f4d2408d180f7aeeacf4c789a1d67 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' 2020-05-16T10:37:14Z k0ga k0ga@shike2.com 2020-05-16T09:48:18Z urn:sha1:bda9c9ffa645ee5e4b2507474ebfa1c5efb889b2 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. 2020-05-09T11:53:50Z Avi Halachmi (:avih) avihpit@yahoo.com 2019-02-26T20:37:49Z urn:sha1:1d590910652519268152eae6b97cf30ace4e90c0 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).