Closing it as soon as we detect that the client has died, means we may
not have drained it completely.
The PTY is either closed _by_ the client application, or by us when we
shutdown the terminal. Thus, leaving it open (until we call
term_shutdown()) is fine.
This requirement is due to the recently added maybe_repair_key_combo()
function, which is making use of xkb_keymap_key_get_mods_for_level().
See also: commit a5b554761a.
When enabled (the default), sixels behave much like normal output; the
start where the cursor is, and the cursor moves with the
sixel. I.e. after emitting a sixel the cursor is left after the image;
either to the right, if private mode 8452 is enabled, or otherwise on
the next line. Terminal content is scrolled up if the sixel is larger
than the screen.
When disabled, sixels *always* start at (0,0), the cursor never moves,
and the terminal content never scrolls.
In other words, the ‘disabled’ mode is a much simpler mode.
All we need to do to support both modes is re-write the sixel-emitting
loop to:
* break early if we’re “out of rows”, i.e. we’ve reached the bottom of
the screen.
* not linefeed, or move the cursor when scrolling is disabled
This patch also fixes a bug in the (new) implementation of private
mode 8452.
When emitting a sixel, we may break it up into smaller pieces, to
ensure a single sixel (as tracked internally) does not cross the
scrollback wrap-around.
The code that checked if we should do a linefeed or not, would skip
the linefeed on the last row of *each* such sixel piece. The correct
thing to do is to skip it only on the last row of the *last* piece.
I chose not to fix this bug in a separate patch since doing so would
have meant re-writing it again when implementing private mode 80.
When disabled (the default), the cursor is positioned on a new line
after emitting a sixel image.
When enabled, the cursor is positioned to the right of the sixel
image.
Closes#363
When enabled (the default), sixels use private color registers. That
is, the color palette from the last sixel is *not* re-used.
When disabled, sixels share (i.e. re-use) the same color palette.
Closes#362
slave: no need to restore signal handlers; they are automatically
restored as long as they are not SIG_IGN (which they never are in
foot).
spawn(): restore signal mask after fork. This fixes an issue where a
terminal spawned with ctrl+shift+n did not terminate when its shell
exited.
Closes#366
Foot previously responded with window local coordinates.
But, XTerm responds with screen *absolute* coordinates. This isn’t
possible under Wayland, thus we now report (0,0) instead. Same as we
do for ‘CSI 13 ; 0 t’.
It’s ok to let the receiving end handle formatting C0 control
characters in bracketed paste mode.
In fact, we *must* let them through. Otherwise it is impossible to
paste e.g. tabs into editors and similar applications.
It’s ok to let the receiving end handle formatting C0 control
characters in bracketed paste mode.
In fact, we *must* let them through. Otherwise it is impossible to
paste e.g. tabs into editors and similar applications.
To reproduce issue:
- Launch an IME from inside foot
- Type in some preedit text
- Use Ctrl-C to close the IME
- IME text stays in terminal until focus is changed
To reproduce issue:
- Launch an IME from inside foot
- Type in some preedit text
- Use Ctrl-C to close the IME
- IME text stays in terminal until focus is changed
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).
