These two buttons were encoded using the *exact* same numbers as
button 4 and 5 (scroll wheel up/down), making it impossible to
distinguish them.
The relevant section from XTerm’s control sequences documentation is:
Some wheel mice can send additional button events, e.g., by tilting the
scroll wheel left and right.
Additional buttons are encoded like the wheel mice,
o by adding 64 (for buttons 6 and 7), or
o by adding 128 (for buttons 8 through 11).
wayland-client-protocol.h:
Negative values for either rate or delay are illegal. A rate of
zero will disable any repeating (regardless of the value of
delay).
This fixes a division-by-zero crash.
When set, the grid contents is centered in the window. I.e. the
left/right and top/bottom margins are equal (+- 1px).
This causes the content to “jump” while doing an interactive resize,
but may still be preferred in e.g. a tiling WM.
Closes#273
When tweak.allow-overflowing-double-width-glyphs=yes, then certain
glyphs are allowed to overflow into the neighbouring cell.
However, if the cell “owning” the double-width glyph is erased (_only_
that cell), then the cell overflowed into is not redrawn, causing
part of the double-width glyph to remain on screen.
To avoid checking for these glyphs when printing to the terminal (i.e
at parse time), simply mark both cells as dirty when we render the
overflowing glyph.
Yes, this means that the cells will always be re-rendered. We count on
them only making up a small portion of the screen.
Shutdown the terminal when the client process terminates, not when the
ptmx file descriptor is closed.
This fixes an issue where the terminal remains running after the
client process has terminated, if it spawned child processes that
inherited the ptmx file descriptor.
This _should_ only happen when we’re doing a partial PGO build, since
then the script is run in the parent terminal. In this case, the user
is expected to use --rows/--cols anyway.
This _should_ only happen when we’re doing a partial PGO build, since
then the script is run in the parent terminal. In this case, the user
is expected to use --rows/--cols anyway.
We use pre-multiplied alpha color channels, but were having bad
rounding errors due to the alpha divider being truncated to an
integer.
The algorithm for pre-multiplying a color channel is:
alpha_divider = 0xffff / alpha
pre_mult_color = color / alpha_divider
In order to fix the rounding errors, we could turn ‘alpha_divider’
into a double.
That however would introduce a performance penalty since now we’d need
to do floating point math for each cell.
The algorithm can be trivially converted to:
pre_mult_color = color * alpha / 0xffff
Since both color and alpa values are < 65536, the multiplication is
“safe”; it will not overflow an uint32_t.
Closes#249