Now that we have a more regular domain-shaped serial thingy,
refactor the `wezterm serial` command to re-use the common
gui setup and running logic. This removes some FIXMEs from
around the wonky setup of the domain, which is nice.
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.
If you haven't assigned `config.ssh_domains` to something else,
this commit will populate it from the hosts it finds in your
ssh config file.
First it will emit no-multiplexing entries that allow ad-hoc
ssh connections.
Then it will emit wezterm multiplexing enabled versions of those
entries.
This got broken around the time we started to re-exec the mux
server. Since the fd was CLOEXEC we'd essentially unlock and
ignore the lock at the point we'd re-exec.
This commit allows the fd to remain open and locked across
the exec, and causes the exec'd process to set CLOEXEC by
explicitly telling it about the log fd, so that shells and
things spawned by the mux don't hold the lock.
Lua appears to populate package.path to something based on the
executable path on windows, but since it uses msvcrt in ANSI mode,
that string is encoded in whatever 8-bit MBCS is configured by
the host system ACP setting.
Rust expects that to be UTF-8, but Windows doesn't guarantee it.
This commit updates the manifest for wezterm-gui to tell Windows
that it wants its ACP to be set to UTF-8 prior to launch, which
should resolve this situation for the GUI.
This commit also introduces a more cut-down manifest for the
console-subsystem executables that also use the lua config layer,
which should hopefully resolve this issue for them.
This commit was authored on a mac, so fingers crossed that it
even compiles properly on windows!
refs: https://github.com/wez/wezterm/issues/3390
Work harder to notice and handle the PaneRemoved notification
more centrally, which allows removing some earlier workarounds.
Now when we receive PaneRemoved, we take the opportunity to handle
missing mapping or stale mapping between local and remote ids and
perform a resync before continuing to handle the PaneRemoved message.
Doing it this way means that we don't need to second guess the timing
of notification or the resync, so we end up with the correct sequence
of notifications, and the result is the correct size of the splits
because the local and remote aren't independently managing the
the pane removal with conflicting ideas of the new size.
refs: https://github.com/wez/wezterm/issues/3386
It's a tremendous PITA for the user to do this at the system level on a
mac, where it is sorely needed. This commit allows raising to a desired
minimum level, but won't decrease from an already larger soft limit.
refs: https://github.com/wez/wezterm/discussions/3353
- v2.0 no longer derives a bunch of traits (Debug, Clone, Copy, PartialEq, Eq)
by default, so I manually derived them.
- It also changed the snapshot results so I updated them:
An empty bitflags struct is no longer displayed as `None` but as
`BitFlags(0x0)`.
- `bits` is no longer a field but a method so I added the missing
parenthesis.
Add a link to regex syntax supported in wezterm, so eg. we have a way to know that perl character class '\c' is not supported and instead we can use the ascii equivalent [:cntrl:]
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 fixes a surprising interaction between copy mode and the
command palette, but is also the root cause of another issue
with CharSelect mode.
refs: https://github.com/wez/wezterm/issues/2947
