Remove an unsafe global variable and replace with a member variable
that works similarly to the drag tracking.
Doing this from a mac... may not compile on a windows box!
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
Broken config could cause the gui to exit before it would normally
print the config warnings and errors, making it harder to understand
what is going on.
This commit bundles the config error text together with whatever
caused it to error out in the fatal error case.
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.
