If we decide we want re-use and existing gui due to config differences
we shouldn't then publish the new, differently configured, gui as
the canonical path for that display/class.
Clarify the message that we print when re-using an existing gui
in case someone doesn't want that behavior.
That top level config/src/lib.rs has been too big for too long.
Break it up a little.
(I recommend running `cargo clean` if you're updating across
this change to avoid a rust ICE with it cached on-disk state)
Previously, it would skip loading the initial config and allow
loading it later by using the reload hotkey. That reload behavior
was an accident!
Another problem with the old approach is that everything else was
set up as if the config had been loaded, which is now causing
confusion for code that wants to decide whether we are using
that configuration or not.
This commit formalizes the skip by remembering that state globally.
This change helps to simplify some special cases around command
line overrides as well, as well as allows cli overrides to take
effect when the user doesn't have a config file.
When a dead key is composing, we gave no information about what was
composing. Contrast with Windows and macOS where we show the first
key in the composition as part of that state.
This commit makes an attempt to populate equivalent information.
It's a bit more complex with the xkeyboard stuff as there can be
multiple combining sequences and there's no guarantee that we can
show a meaningful label.
We try our best for the common case of a single dead key, and have
a probably reasonable fall back for other cases where we don't
other get that information.
This allows removing DeadKeyStatus::Holding.
They have their own versions of these options, and logically it doesn't
make sense to use the default_prog from the `local` domain with a wsl
domain.
refs: #1242
This returns the default set of domains that would be populated
in the wsl_domains config. This is useful if you want to override
eg: the default_prog for specific domain(s), or want to otherwise
add additional variations on the default list.
When set, changes the default domain to the domain with the specified
name, which potentially affects the default program.
eg: default_domain = "WSL:Ubuntu-18.04" will cause the initial tab
to be spawned via WSL.
The idea is that we want to be able to spawn into wsl with the
convenience of a local domain, but without the awkwardness of
it having a different filesystem namespace.
It would also be great to be able to spawn a new tab or pane
in the same domain and pick up the cwd of the existing one.
The WslDomain allows the user to explicitly list WslDomains
and control eg: default shell, username and so on, but wezterm
will pre-fill a default list of domains based on the `wsl -l`
output that we were already using in the launcher menu.
The existing LocalDomain has been augmented to understand that
it may need to fixup a command invocation and that gives it
the opportunity to rewrite the command so that we can launch
it via `wsl.exe` and pass down the cwd and so on.
This same technique might be extensible to eg: docker instances
in the future.
This commit:
* Introduces `wsl_domains` config and its default list of wsl
distributions
* Creates LocalDomain instances from that list
* The launcher menu allows spawning a new tab via one of those domains
lalt-` is technically a dead key combo, so we entered dead key
processing, then realized that
`send_composed_key_when_left_alt_is_pressed == false` and that
we should ignore the dead-key-ness of the combo, but returned
a composed result, which had the modifiers discarded.
The correct way to handle this is to signal that it wasn't
dead after all and to allow the main flow to build the KeyEvent
as normal.
The client machinery would try to spawn an async attempt at
detaching the unixdomain from the mux on shutdown, but since
we're in the middle of tearing down the scoped executor,
we could sometimes panic.
The client we have in this situation isn't actually associated
with a domain, so we don't need to detach in that situation.
Formalize that by making it an Option, and address the
fanout.
Using the new publish/discovery stuff from the past couple of commits,
if we can find a matching socket path for a running gui, and the
configuration is likely a match, then use the mux protocol to talk
to the already running gui and ask it to spawn the equivalent program
into the same process.
refs: https://github.com/wez/wezterm/discussions/1486
We need 100% of the info for it to work correctly, so this commit:
* Exposes the keyboard encoding mode via the Pane trait
* Adds the scan code to the RawKeyEvent
* Has the GUI perform the encoding if the keyboard is set that way
* Removes the basic encoder from termwiz in favor of the gui level one
The net result is that we bypass the Pane::key_up/Pane::key_down methods
in almost all cases when the encoding mode is set to win32-input-mode.
There is now a config option: allow_win32_input_mode that can be
used to prevent using this mode.
refs: #1509
When spawned with no WEZTERM_UNIX_SOCKET environment set,
we now prefer to resolve the gui instance, falling back to
the mux if it doesn't look like the gui is running.
`wezterm cli --prefer-mux` will use the original behavior of
trying to resolve the path from the unix domain in the config.
