I think the future for this is to extend the Pattern type to accept
a list of regexes and use a RegexSet to unambiguously handle multiple
patterns with captures.
That might help a little with https://github.com/wez/wezterm/issues/3247
but the stated use in that issue may not even work with the rust
regex crate.
For now we do the simple thing and match the user's patterns
first.
refs: https://github.com/wez/wezterm/issues/3456
Allows prompting the user to select from a list and then
triggering some action on the selected item.
This is the guts of the launcher menu hooked up to user-supplied
arbitrary entries.
Previously, we'd record the focused pane only in the per-client
view.
That status didn't propagate through the model fully, leading to
inconsistencies when using activate-pane-direction.
This commit does the full model update to force that through.
I may regret this later: the focus state was intended to be
a per-client attribute and this effectively prevents that
from ever being useful.
Maybe the per-client state should just be removed?
Will ponder that later.
refs: https://github.com/wez/wezterm/issues/3448
refs: https://github.com/wez/wezterm/issues/3387
Also sneaking in here is not updating the last input time
for a client unless the input was taken by a user.
This had a referencing issue, similar to the more recent GLOBALS
issue.
The resolution in this case is a lot simpler: we can just return
a regular lua table and use all the same underlying semantics,
but stick a metatable over the top to handle assignment and
provide the strict mode method.
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
The server-side ownership of the palette is a stumbling block for
many users, so let's fix it.
This commit allows the client to pass its configured palette to
the server when it connects, and when the config is changed.
That palette takes precedence over the palette from the server config.
However, if the remote application uses any escape sequences that
redefine the color palette, the color palette that was active at
that point in time is forked and use as the basis, and will remain
the active palette until the palette is reset via escape sequences.
refs: https://github.com/wez/wezterm/issues/2686
refs: https://github.com/wez/wezterm/issues/3397
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.
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.
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
