otherwise, the termwiz line reader can become confused and
fail to recognize key presses like `(` which have SHIFT and LEFT_SHIFT
set.
refs: https://github.com/wez/wezterm/issues/3999
Factor out the probe_screen_size method from the Terminal
trait and put it into a ProbeCapabilities struct.
This makes it easier to introduce other sorts of probed
information without making the Terminal trait grow all sorts
of additional methods.
A Terminal may choose not to support probing, which it cannot
if it doesn't have Read + Write handles to an underlying terminal
(such as some special cases in wezterm).
Neither of these understand image protocols, and both are
an additional processing layer between the application and
wezterm.
This commit detects and wraps OSC sequences in tmux's passthru
sequence so that the data is passed on to wezterm rather than
elided from the data stream.
For image protocols in both tmux and conpty, work a little
smarter and explicitly move the cursor position to the same
location that wezterm would move it to. That prevents the
display from being as mangled by tmux/conpty due to a diverging
understanding of the cursor position.
The logic isn't perfect, and can result in the x-coordinate
being incorrect, and this won't work with the new --position
argument either in its current state, without adding a lot
of complexity to deal with scrolling and relative and absolute
positioning handling.
To facilitate that, a new termwiz Terminal trait method has
been added to probe the terminal name, version, cell and pixel
dimensions. It's not pretty.
refs: https://github.com/wez/wezterm/issues/3624
refs: https://github.com/wez/wezterm/issues/3716
ssh connection or host authentication errors would not be displayed
when the config was in its default exit_behavior=Close state.
This commit introduces some plumbing to allow a pane to override
the effective exit_behavior value, so that ssh sessions can now
rewrite it to CloseOnCleanExit while they are in the process
of connecting.
refs: #3941
I believe that this was obsoleted long ago by the ThreadedWriter
logic that is present in the terminal implementation so we no
longer need to limit the write chunk size.
refs: #3683
If the client program is drip feeding us input at a rate faster than 1
character per mux_output_parser_coalesce_delay_ms (e.g. it is printing
output read from a serial port faster than this), we would previously
wait indefinitely for new input, because we would always poll with a new
timeout [...]delay_ms in the future. In the worst case, this would create
a busy loop that starves the other panes of an opportunity to read from
their ptys, making all of them unresponsive. Address this by making a
note of when the first character was read, and do not wait longer than
[...]delay_ms after this time.
Fixes#3466.
https://github.com/wez/wezterm/discussions/3480#discussioncomment-5567569
mentioned that running `wezterm cli spawn --domain-name SSH:foo`,
closing that tab and running `wezterm cli spawn --domain-name SSH:foo`
again failed.
The error message had no useful context.
This commit adds more context.
The stack trace in https://github.com/wez/wezterm/issues/3425
shows a recursive borrow triggered indirectly by spawning
a subprocess and having that trigger the wndproc.
This commit doesn't really fix the recursive problem, but may
sidestep it, and it's probably best to avoid always running
the `wsl` command to get this list anyway, similar to the
change in 25255d90d6
refs: https://github.com/wez/wezterm/issues/3425
If the target domain_id doesn't match the source pane.domain_id(),
then we consider the filesystem namespace to be incompatible and
won't try to use it.
refs: https://github.com/wez/wezterm/issues/3442
This commit teaches the config about SerialDomains, and the mux
layer about constructing a SerialDomain, then changes the GUI
layer to use those pieces to set up `wezterm serial`.
A new `serial_ports` config is added, and the GUI layer knows how
to apply it to the set of domains in the mux.
The result of this is that you can now define a domain for each
serial port and spawn a serial connection into a new tab or window
in your running wezterm gui instance.
Three issues:
* The initial connect would leave the dpi assigned to 0, resulting
in incorrect scaling when using imgcat until the window was resized
and the correct dpi was passed up.
* On resize, we'd only compare the row/col count and not notice changes
in pixel dimensions/dpi
* On the server side, when processing a resize and recomputing
the tab size, we would omit the pixel dimensions and leave
the resulting tabs and panes with 0 dimensions, breaking imgcat
because it thought the window was 0x0.
refs: https://github.com/wez/wezterm/issues/3366
This commit causes the mux to generate a PaneFocused notification
when the active pane is changed.
The mux server will forward that as a unilateral PDU to connected
clients.
The clientpane implementation will handle that by applying the
same state to the local mux.
refs: #2863
Previously, when resizing a tab, we'd unzoom it, recompute the resize
deltas and adjust every pane's non-zoomed position and re-zoom the
original pane.
When the alt screen is active, wezterm doesn't reflow resized lines,
and there a number of situations where the only effective change to
the line was updating a seqno; the content of those panes doesn't
actually update until the application(s) attached to the PTY
receive SIGWINCH from the kernel.
Since we were resizing the zoomed pane twice in quick succession
we could double-tap SIGWINCH and the application might coalesce
and process only one of the resize events.
The result of that was that we might see the state from either
the first or second resize event and then not get any other updates
until the application repainted itself.
This commit re-structures the resize behavior around zooms so that
we only resize the zoomed pane. When unzooming we'll fixup the
no-zoomed sizes for the whole tab. That means that we need to
store the pre-zoom size in order to correctly calculate those
sizes for the case where a pane was zoomed, the tab resized, and
then the pane was unzoomed again.
refs: https://github.com/wez/wezterm/issues/3068
