The sequence \e[Nb prints the last printed char N (more) times if it's
printable, and it's ignored after newline or other control chars.
This is Ecma-048/ANSI-X3.6 sequence and not DEC VT. It's supported by
xterm, and ncurses uses it when possible, e.g. when TERM is xterm* (and
with this commit also st*).
xterm supports only codepoints<=255, possibly due to internal limits.
We support any value/codepoint which was placed in a cell.
To test:
- tput rep 65 4 -> prints 'AAAA'
- printf "\342\225\246\033[4b" -> prints U+2566 1+4 times.
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).
This line didn't work at mshortcuts at config.h:
/* mask button function arg release */
{ ShiftMask, Button2, selpaste, {.i = 0}, 1 },
and now it does work.
The issue was that XButtonEvent.state is "the logical state ... just prior
to the event", which means that on release the state has the Button2Mask
bit set because button2 was down just before it was released.
The issue didn't manifest with the default shift + middle-click on release
(to override mouse mode) because its specified modifier is XK_ANY_MOD, at
which case match(...) ignores any specific bits and simply returns true.
The issue also doesn't manifest on press, because prior to the event
Button<N> was not down and its mask bit is not set.
Fix by filtering out the mask of the button which we're currently matching.
We could have said "well, that's how button events behave, you should
use ShiftMask|Button2Mask for release", but this both not obvious to
figure out, and specifically here always filtering does not prevent
configuring any useful modifiers combination. So it's a win-win.
Strings which an application sends to the terminal in OSC, DCS, etc
are typically small (title, colors, etc) but one exception is OSC 52
which copies text to the clipboard, and is used for instance by tmux.
Previously st cropped these strings at 512 bytes, which for OSC 52
limited the copied text to 382 bytes (remaining buffer space before
base64). This made it less useful than it can be.
Now it's a dynamic growing buffer. It remains allocated after use,
resets to 512 when a new string starts, or leaked on exit.
Resetting/deallocating the buffer right after use (at strhandle) is
possible with some more code, however, it doesn't always end up used,
and to cover those cases too will require even more code, so resetting
only on new string is good enough for now.
STRescape holds strings in escape sequences such as OSC and DCS, and
its buffer is 512 bytes.
If the input is too big then trailing chars are ignored, but the test
was off-by-1 such that it took 510 chars instead of 511 (before a
terminating NULL is added).
Now the full size can be utilized.
Previously, base64dec checked terminating input '\0' every 4 calls to
base64dec_getc, where the latter progressed one or more chars on each
call, and could read past '\0' in the way it was used.
The input to base64dec currently comes only from OSC 52 escape seq
(copy to clipboard), and reading past '\0' or even past the buffer
boundary was easy to trigger.
Also, even if we could trust external input to be valid base64, there
are different base64 standards, and not all of them require padding
to 4 bytes blocks (using trailing '=' chars).
It didn't affect short OSC 52 strings because the buffer is initialized
to 0's, so typically it did stop within the buffer, but if the string
was trimmed to fit (the buffer is 512 bytes) then it did also read past
the end of the buffer, and the decoded suffix ended up arbitrary.
This patch makes base64dec_getc not progress past '\0', and instead
produce fake trailing padding of '='.
Additionally, at base64dec, if padding is detected at the first or
second byte of a quartet, then we identify it as invalid and abort
(a valid quartet has at least two leading non-padding bytes).
The recent mouse shurtcuts commits allow customization, but ignore
forcemousemod mask (default: shift) as a modifier, for no good reason
other than following the behavior of the KB shortcuts.
Allow using forcemousemod too, which now can be used to invoke
different shortcuts, though the automatic effect of forcemousemod will
be lost for buttons which use mask with forcemousemod.
E.g. the default is:
static uint forcemousemod = ShiftMask;
...
{ XK_ANY_MOD, Button4, ttysend, {.s = "\031"} },
...
where ttysend will be invoked for button4 with any mod when not in mouse
mode, and with shift when in mouse mode.
Now it's possible to do this:
{ ShiftMask, Button4, ttysend, {.s = "foo"} },
{ XK_ANY_MOD, Button4, ttysend, {.s = "\031"} },
Which will invoke ttysend("foo") while shift is held and ttysend("\031")
otherwise. Shift still overrides mouse mode, but will now send "foo".
Previously with this setup the second binding was always invoked
because the forceousemod mask was always removed from the event.
Buttons which don't use forcemousemod behave the same as before.
This is useful e.g. for the scrollback mouse patch, which wants to
configure shift+wheel for scrollback, while keeping the normal behavior
without shift.
Because selpaste is activated on release, a release flag was added to
mouse shortcuts which controls whether activation is on press/release,
and selpaste binding to button2 was moved to config.h .
button1 remains the only hardcoded mouse button - for selection + copy.
Allow forceselmod to override all mouse shortcuts rather than only
selection, and rename it to forcemousemod as it's now more appropriate.
This will affect mouse shortcuts which use mask other than XK_ANY_MOD.
This does not affect the default behavior because the default mouse
shortcuts (wheel) use XK_ANY_MOD, where forceselmod already activated
the override also before this change.
Previously, if a mouse shortcut was configured with a specific mod and
forceselmod was held, then the shortcut did not execute unless the
configured mod included forceselmod.
Avi Halachmi (:avih)andHiltjo Posthuma