This is slightly misusing or misattributing things, but in
the context of the problem at hand, it is OK.
The issue is that palette changes are normally signalled by
the terminal instance in response to escape sequences. Those
changes are propagated to the mux client through the existing
alerting channel.
If the palette is changed implicitly via a config change, then
the terminal doesn't trigger that alert and the mux client(s)
don't know that they need to refresh the palette.
This commit tracks the last config generation per pane and
synthesizes a palette alert when it changes.
It might be better to have another variant of alert to indicate
config changes.
refs: #1526
This doesn't make a huge difference; I think we already addressed
the worst of the overhead with a combination of
eae327efcc
and the more recent commits to avoid over invalidation around
cursor movement and screen scrolling.
The numbers I see are a very small number of bytes per second when
scrolling through eg: vim and aren't crazy or alarming.
So I'm going to consider the related issue resolved!
closes: https://github.com/wez/wezterm/issues/867
If we know that the remote host is a unix system, and that it uses some
version of the posix shell, then we can adjust our command line to cd to
the requested directory (as set by OSC 7) and then exec the requested
command.
That's what SshDomain::assume_unix indicates and what this commit does.
This puts us in a better position for the future to be able
to configure whether we use wezterm, tmux or no multiplexing.
Today we allow wezterm or no multiplexing.
Add docs on this new setting.
refs: https://github.com/wez/wezterm/issues/1456
If an ssh domain is set to use_multiplexer=false, it is now
possible to `wezterm connect` to it.
Previously, it was only possible to connect to domains that
used the mux client.
refs: https://github.com/wez/wezterm/issues/1456
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.
