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
Pull in the enhanced scheme that includes wezterm metadata and colors.
Co-authored-by: Thomas Croft <103956335+thomascft@users.noreply.github.com>
closes: https://github.com/wez/wezterm/pull/3208
- Removes closures and function calls for types that implement default:
```rust
// Change
let _my_str = get_str().unwrap_or(String::new);
// To
let _my_str = get_str().unwrap_or_default();
```
- Uses the `.cloned()/.copied()` methods where possible
- Use function pointer instead of simple closure
May improve performace, as closures generate more code, and this might
unlock some inlining opportunities.
- Use `find` instead of `position(..).next()`
- Use `any` instead of `position(..).next().is_some()/.is_none()`
- Use `first/next` instead of `get(0)/nth(0)`
- Prefer `for` loops over `while let` loops on iterators
May improve performance.
Threads through a GuiPosition from mux window creation to allow it to be
used when the corresponding gui window is created.
SpawnCommand now has an optional position field to use for that purpose.
```lua
wezterm.mux.spawn_window {
position = {
x = 10,
y = 300,
-- Optional origin to use for x and y.
-- Possible values:
-- * "ScreenCoordinateSystem" (this is the default)
-- * "MainScreen" (the primary or main screen)
-- * "ActiveScreen" (whichever screen hosts the active/focused window)
-- * {Named="HDMI-1"} - uses a screen by name. See wezterm.gui.screens()
-- origin = "ScreenCoordinateSystem"
},
}
```
refs: https://github.com/wez/wezterm/issues/2976
Brief usage notes here:
```lua
local wezterm = require 'wezterm'
local a_plugin = wezterm.plugin.require "https://github.com/owner/repo"
local config = wezterm.config_builder()
a_plugin.apply_to_config(config)
return config
```
The referenced repo is expected to have a `plugin/init.lua` file,
and by convention, return a module that exports an `apply_to_config`
function that accepts at least a config builder parameter, but may
pass other parameters, or a lua table with a `config` field that maps
to a config build parameter.
`wezterm.plugin.require` will clone the repo if it doesn't already
exist and store it in the runtime dir under `plugins/NAME` where
`NAME` is derived from the repo URL. Once cloned, the repo is
NOT automatically updated.
Only HTTP (or local filesystem) repos are allowed for the git URL;
we cannot currently use ssh for this due to conflicting version
requirements that I'll take a look at later.
`wezterm.plugin.require` will then perform `require "NAME"`,
and since the default `package.path` now includes the appropriate
location from the runtime dir, the module should load.
Two other functions are available:
`wezterm.plugin.list()` will list the plugin repos.
`wezterm.plugin.update_all()` will attempt to fast-forward or `pull
--rebase` each of the repos it finds. It doesn't currently do anything
proactive to reload the configuration afterwards; the user will need to
do that themselves.
