* Change aliasing to exact matches of the color data.
* Don't "GC" away schemes that are no longer reachable from aggregators;
just because they are no longer listed elsewhere, doesn't mean that we
should remove the name/scheme from wezterm if it was already made
available in an earlier release.
refs: #3831
It's a little limited in the scope of its detection: we have a built-in
list of tiling WM environments and if the current one is on the list
then we set an appropriate value for this option.
The list currently has just a single entry.
It's obvious that Nushell is intended to be skipped by default for close
confirmation. However, on Windows, Nushell instances are named `nu.exe`,
not `nu`, so they don't get skip-closed properly. Add `nu.exe` alongside
`nu`, so Windows behaves as expected.
Previously, the config crate would get rebuilt each time the
git state changed, which has a lot of fan out and makes the build
take longer than it really needs to.
This commit breaks out the version changing stuff to its own crate
and then provides a runtime mechanism for assigning the version
information back into the config crate.
The env-bootstrap crate is responsible for setting that up.
The stack trace in https://github.com/wez/wezterm/issues/3425
shows a recursive borrow triggered indirectly by spawning
a subprocess and having that trigger the wndproc.
This commit doesn't really fix the recursive problem, but may
sidestep it, and it's probably best to avoid always running
the `wsl` command to get this list anyway, similar to the
change in 25255d90d6
refs: https://github.com/wez/wezterm/issues/3425
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.
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.
At 80x24 (< 2k cells), sending all 24 lines of the viewport as an
optimistic prefetch is "OK", but for full screen 4k (80*250 = 20k cells)
the volume is oversized and pushes latency up.
This commit dials that back down to the minimal useful data; the
cursor row + any changed rows in the viewport. When navigating
in vim that reduces things down to 2 rows of prefetch per movement,
assuming that the status line is being updated to show the cursor
position.
This feels a little more snappy for me.
refs: https://github.com/wez/wezterm/issues/2503
refs: https://github.com/wez/wezterm/issues/1872
I noticed that in debug builds, `wezterm set-working-directory` had
high/variable latency, and I traced part of it to the ssh config parsing
logic.
Make that lazily evaluate the ssh config.
refs: #3402
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.
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.
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
On macOS prefer CMD, but on other platform prioritize shortcuts
that don't use CMD, as those tend to reserve the CMD based shortcuts
for the system.
Allow specifying how many shortcuts to show if an action has
multiple assignments. The default is 1.
refs: https://github.com/wez/wezterm/issues/3335
added a new `ui_key_cap_rendering` option that accepts the following
values:
```lua
-- Super, Meta, Ctrl, Shift
config.ui_key_cap_rendering = 'UnixLong'
-- Super, M, C, S
config.ui_key_cap_rendering = 'Emacs'
-- Apple macOS style symbols
config.ui_key_cap_rendering = 'AppleSymbols'
-- Win, Alt, Ctrl, Shift
config.ui_key_cap_rendering = 'WindowsLong'
-- Like WindowsLong, but using a logo for the Win key
config.ui_key_cap_rendering = 'WindowsSymbols'
```
refs: https://github.com/wez/wezterm/issues/3335
Given an assignment like this:
```
{
key = "b",
mods = "ALT",
action = wezterm.action.SplitPane {
direction = 'Right',
command = {
label = 'Bash Right',
args = {'/usr/bin/bash' }
}
}
}
```
we should show the label from the command in the palette.
That's what this commit enables.
If there is no label, but the arguments are set, then the
arguments will be shown instead.
refs: #3252
