We failed to convert the byte-indices to cell indices, resulting in a
box cursor covering the entire pre-edit string.
Note that in addition to fixing the translation from byte index to
cell index, the rendered had to be updated to dirty one extra cell
from the original grid.
Without this, we left trailing cursors behind us when the user deleted
text from the pre-edit string.
When rendering the search input box, do the same ad-hoc workaround for
combining characters with a positive x-offset as we do when rendering
normal grid cells.
In this case, we don’t *know* when we’re dealing with combining
characters. But we can detect zero-width characters. For these, check
their glyph’s x-offset. If positive, adjust it like we do when
rendering combining glyphs in the main grid, to ensure the glyph is
positioned over the _previous_ character, not the next.
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 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.
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
This extends the new ‘dpi-aware’ option with a new default value,
‘auto’.
When set to ‘auto’, fonts are sized using monitors’ DPI when output
scaling is disabled. When output scaling is enabled, fonts are instead
sized using the scaling factor.
The reasoning here is that a user that has enabled output scaling is
obviously *not* relying on DPI scaling.
Output scaling can also be a way to compensate for different viewing
distances, in which case we do *not* want to break that by using DPI
scaling.
Users can still force DPI-only font sizing by setting ‘dpi-aware=yes’,
or disable it completely by setting ‘dpi-aware=no’.
Take ‘\E(#0’ for example - this is *not* the same as ‘\E(0’.
Up until now, foot has however treated them as the same escape,
because the handler for ‘\E(0’ didn’t verify there weren’t any _other_
private characters present.
Fix this by turning the ‘private’ array into a single 4-byte
integer. This allows us to match *all* privates with a single
comparison.
Private characters are added to the LSB first, and MSB last. This
means we can check for single privates in pretty much the same way as
before:
switch (term->vt.private) {
case ‘?’:
...
break;
}
Checking for two (or more) is much uglier, but foot only supports
a *single* escape with two privates, and no escapes with three or
more:
switch (term->vt.private) {
case 0x243f: /* ‘?$’ */
...
break;
}
The ‘clear’ action remains simple (and fast), with a single write
operation.
Collecting privates is potentially _slightly_ more complex than
before; we now need mask and compare, instead of simply comparing,
when checking how many privates we already have.
We _could_ add a counter, which would make collecting privates easier,
but this would add an additional write to the ‘clean’ action which is
really bad since it’s in the hot path.
This fixes issues with de-synchronized frames being rendered; we may
have scheduled a redraw earlier, that hasn’t yet triggered (probably
because we’re waiting for a frame callback), when we enable
application synchronized updates.
This means we risk rendering a partially updated state when the frame
callback finally arrives, if the application hasn’t yet ended its
synchronized update.
Well this is embarrassing; the sub-parameter versions of the 38/48 SGR
escapes all required an extra ‘:2’ that wasn’t supposed to be there,
causing all the other sub-parameters to be shifted one step to the
right.
That is, foot expected e.g. 38:2:2:r:g:b, or 38:2:5:idx when the
correct sequences are 38:2:cs:r:g:b and 38:5:idx.
I.e. I mixed up the color-space ID (cs) of 38:2 with *type* of color:
RGB or indexed.
In addition to fixing this, this patch also adds support for a
“bastard” version of the sub-parameter based RGB escapes, where the
color-space identifier has been left out: e.g. 38:2:r:g:b. This
sequence is invalid, but applications tend to “forget” the color-space
ID...
As long as the mouse button was *pressed* while the pointer was inside
the grid, we want to keep reporting motion events until the button is
released.
Even when the pointer moves outside the grid (but in this case, the
reported coordinates are bounded by the grid size).
This patch also tries to improve multi-button handling (i.e. multiple
buttons pressed at the same time), and the events we report to the
client for these, in the following ways:
* Motion events now report the *initial* button. That is, if you start
a drag operation with the LEFT button, then press RIGHT (before
releasing LEFT), keep reporting LEFT in the motion events.
* Mouse release events are reported for *any* button, as long as the
pointer is *inside* the grid, *or*, the button released was the
button used to start a drag operation.
The last point is important; if we have reported a button press
followed by motion events (i.e. a drag operation), we need to report
the button release, *even* if the pointer is outside the grid.
Note that the client may receive unbalanced button press/release
events in the following ways if the user pressed one, and then a
second button *inside* the grid, then releases the *first*
button (possibly outside the grid), and finally releases the *second*
button *outside* the grid.
In this case, both buttons will report press events. The first button
will report a release event since it is the initial button in the drag
operation.
However, we don’t track the fact that the second button is being
pressed, and thus if it is released outside the grid, it wont generate
a release event.
