Need to use a newer version of libssh-rs that can report this state,
as the underlying libssh doesn't fold it into the process exit
status.
refs: https://github.com/wez/wezterm/issues/3095
I don't recall changing it to copy to the primary selection only, and
it doesn't feel like it is something I would want anyway, and I think
it generally makes things annoying for all but power users
https://fosstodon.org/@trentskunk@mstdn.social/109808345817367266
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
Hi,
I encountered an error while trying to upgrade Wezterm to a newer nightly build on MacOS using the previous brew command. The error message was:
“Error: Cask wezterm-nightly exists in multiple taps:
homebrew/cask-versions/wezterm-nightly
wez/wezterm/wezterm-nightly”
To resolve this issue temporarily, I modified the shell script to use the "wez/wezterm/wezterm-nightly" tap. However, I wanted to check if it's preferable to use the "homebrew/cask-versions/wezterm-nightly" tap instead. Please let me know your thoughts on this.
Thanks!
Threads through a GuiPosition from mux window creation to allow it to be
used when the corresponding gui window is created.
SpawnCommand now has an optional position field to use for that purpose.
```lua
wezterm.mux.spawn_window {
position = {
x = 10,
y = 300,
-- Optional origin to use for x and y.
-- Possible values:
-- * "ScreenCoordinateSystem" (this is the default)
-- * "MainScreen" (the primary or main screen)
-- * "ActiveScreen" (whichever screen hosts the active/focused window)
-- * {Named="HDMI-1"} - uses a screen by name. See wezterm.gui.screens()
-- origin = "ScreenCoordinateSystem"
},
}
```
refs: https://github.com/wez/wezterm/issues/2976
The motivation here was to remove some similar but not quite the same
logic that existed for starting up when using `wezterm connect`.
Now `wezterm connect DOMAIN` is implemented as `wezterm start --domain
DOMAIN --attach --always-new-process` and a little extra hand-wave to
ensure that the default domain is set correctly.
The startup events have been refactored a bit; a new gui-attached
event is emitted after attaching and starting any default programs
in the selected domain at startup.
That event can be used to maximize windows and so on, if desired.
The gui-attached event is independent of the startup command and fires
for `wezterm connect`, which `gui-startup` did not (and could not) do.
