Wait until set_inner_size() has finished before repainting. If we
repaint while our request to resize is in progress, our understanding of
the current size of the window may be inconsistent with the actual size,
causing the rendered contents of the window to bounce around.
dependabot is trying to update pulldown-cmark, but it won't
work because the API has changed.
The update window is not enabled by default and I don't think
anyone uses it anyway, so let's just remove it and have less
code to compile and maintain.
closes: https://github.com/wez/wezterm/pull/4964
These are used to signal, after a set_inner_size() call, at what point
we can expect any and all of its related Resized events to have already
been dispatched. SetInnerSizeCompleted events are currently used to fix
a race condition in rescaling the terminal in which the number of cells
of the terminal (e.g., 80x24) can change when quickly rescaling the
terminal.
This reverts commit 2c95b98447.
More people were vocally and sometimes toxic about this change
than were in favor of it.
I'm just going to revert it and leave the original issue open.
refs: https://github.com/wez/wezterm/issues/2882
Otherwise it is just hidden forever. We can't use the proper declarative
interface, because we are faking quite some stuff for "-e", so instead
we mention it explicitly in the help output.
This is done for compatibility, as many tools assume that running a
command with "$TERMINAL -e $COMMAND" blocks until the command is
finished.
For example some tools delete a needed file after the command returns.
But since we always return immediately (in case --always-new-process is
not provided and if another wezterm instance is already running), this
would mean that the file is deleted before the command could do
anything.
Fixes#4523
This allows individual call sites to be able to force an immediate
resolution of the process information.
This should help to address https://github.com/wez/wezterm/issues/4811
wherein the problem seems to be that the cwd used for a new spawn
is taken from a stale read.
* Removed title update from main render loop
* Add to PaneFocused event
* term: only emit Alert::OutputSinceFocusLost for the first
seqno bump after losing focus, rather than on every bump.
That event indirectly causes the title to update
refs: https://github.com/wez/wezterm/issues/4788
On X11, this information is set as part of the hints given to the window
manager. When resizing the terminal, many X11 window managers will now
correctly report the current cell size of the terminal (e.g., 80x24) as
an overlay when resizing the window.
It's not clear exactly how this triggers, but in setups where
a compose key has been configured (against the default for the
configured keyboard layout), it seems as though certain events
that indicate when composition is complete are not delivered,
leaving the compose cursor in an inconsistent state.
This commit attempts to detect that composing->!composing
state transition and bubble it up; when we return Nothing
and had previously had a composition string we're return
a bool to cause the caller to emit an event that clears
the composition state.
I'm not totally sure this is 100% right, but I think
it may help with the case we're discussing in
https://github.com/wez/wezterm/issues/4841
