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.
config_builder helps to make issues more visible/useful in the case
where you may have typod a config option, or otherwise assigned
an incorrect value.
In https://github.com/wez/wezterm/issues/2932 the user desired to have
brightened text without the boldness, as they were accustomed to that
behavior in a couple of other terminal emulators.
This commit changes the `bold_brightens_ansi_colors` from a simple
boolean to a tristate that allows for not changing the brightness,
changing the brightness, and changing the brightness while adjusting
the boldness down to normal levels.
boolean values are accepted for backwards compatibility.
This commit introduces a rough first pass at a command palette modal.
It is an adaptation of the emoji character selector and needs
refinement.
Importantly, the default pane selector key assignment now calls
into this new command palette instead.
refs: https://github.com/wez/wezterm/issues/1485
This allows defining those help actions that open URLs in the main
commands list, and not just for the macOS Help menu.
refs: https://github.com/wez/wezterm/issues/1485
I'd like to push that into the status bar, so nudge people towards
that in the docs for this.
There is a config option to restore it. I'd like to ultimately
remove that though.
refs: https://github.com/wez/wezterm/discussions/2542
* Expose `activate-pane-direction` cli command
Add a new subcommand for `wezterm cli` called `activate-pane-direction`.
It allows switching the active pane in the current tab in the given
direction.
* Bump codec version
* Replace boolean flags with a single direction arg
* Run cargo fmt
This provides a means for more easily extending the default key
tables without forcing the user to recreate the entire config
for themselves.
wezterm.gui.default_keys is also added by this, but it is likely
not as useful.
ad9490ee8f unset SHELL from the
environment on startup which had the consequence of causing
`os.getenv("SHELL")` to return `nil` when used in the config file.
Rather than simply restoring SHELL env var, recognize that reading
the environment from a long lived process is prone to seeing
stable environment forever.
We already compensate for this in the pty crate's understanding
of the base environment, so this commit patches `os.getenv`
and replaces it with our own imlementation that uses that same
logic.
The base environment logic has been extended to set SHELL from
the passwd database to round things out.
refs: https://github.com/wez/wezterm/discussions/2481
There are caveats to determining this, but when we think
password entry is enabled, switch the cursor to the font-awesome
lock glyph instead of the normal cursor sprite.
fa_lock is used because it is monochrome and can thus be tinted
to the configured cursor color, and it respects blinking/easing.
refs: https://github.com/wez/wezterm/issues/2460
The default behavior for charselect is to show the recent category
if you have previously used it, otherwise, show the default emotion
category.
refs: https://github.com/wez/wezterm/issues/2163
CTRL-SHIFT-U is a new default key assignment for this new modal.
It opens up a fuzzy searchable browser that defaults to showing
emoji/emoticons. The category can by cycled through the suggested
emoji categories using CTRL-r. Unlike the system emoji palette,
wezterm includes a category for nerdfont symbols, and another
that is a list of all unicode codepoint names, so you should be
able to browse for pretty much any codepoint you can think of.
The modal also allows fuzzy searching based on:
* The official unicode name
* The github shortcode
* codepoint value in hex
so if you know the codepoint value but not the name, you can
still find a way to input what you're looking for.
Pressing Enter will copy the selected item to the clipboard
send it to the active pane, and cancel the modal. You can therefore
repeat the insert by simply pasting.
I plan to add frecency to this in a later commit: that way the
frequently/recently used selections will show in a category of
their own and make it easier to re-input them.
refs: https://github.com/wez/wezterm/issues/2163
This is really a proof of concept commit; I want to be able to pass
more structured data into the shader as uniforms and the basic
macros provided by glium make that a bit awkward.
What I came up with is a slightly more dynamic uniform builder
thingy.
I'm using this to pass in a copy of the various blinking easing
functions.
Those are incomplete and unused, but it shows that the technique works.
It's not the first time that I've solved a problem by slowing things
down... in this situation, a couple of very inefficient TUI programs had
flickering outputs in wezterm because they were filling a buffer with a
bunch of spaces to erase a screen before sending the main body of their
updates in a subsequent buffer chunk. wezterm would render the
intervening partially blank frame and appear to flicker.
The resolution is to add a small delay (3ms by default) before sending
data to the terminal model. If the output is readable in that time
we'll accumulate it with the pending set of actions so that the
whole batch can be applied "more atomically".
Take care: `time cat bigfile` is sensitive to this, so we want to
keep the latency as small as possible, and we also want to avoid
accumulating actions and only flushing them at the end of the file.
We use the existing buffer size (~1MB) as a threshold: we bump
a count of the number of input bytes that resulted in the current
set of actions, and if that exceeds that buffer size we flush it.
refs: https://github.com/wez/wezterm/issues/2443
The prior mutually exclusive behavior kept surprising people so let's
just flip this around.
This is potentially a "breaking" change for folks, but I think it is
worth it.
Allows the following assignment actions; I was just over-using z for
no real reason, I'm not suggesting that these are good assignments.
```
-- move the cursor backwards to the start of the current zone, or
-- to the prior zone if already at the start
{ key = 'z', mods = 'NONE', action = act.CopyMode 'MoveBackwardSemanticZone' },
-- move the cursor forwards to the start of the next zone
{ key = 'Z', mods = 'NONE', action = act.CopyMode 'MoveForwardSemanticZone' },
-- start selecting by zone: both the start point and the cursor
-- position will be expanded to the containing zone and the union
-- of those two will be used for the selection
{
key = 'z',
mods = 'CTRL',
action = act.CopyMode { SetSelectionMode = 'SemanticZone' },
},
-- like MoveBackwardSemanticZone by only considers zones of the
-- specified type
{ key = 'z', mods = 'ALT', action = act.CopyMode { MoveBackwardZoneOfType ='Output' }},
-- like MoveForwardSemanticZone by only considers zones of the
-- specified type
{ key = 'Z', mods = 'ALT', action = act.CopyMode { MoveForwardZoneOfType ='Output' }},
```
refs: https://github.com/wez/wezterm/issues/2346
They prevented using other types of mouse events!
We don't have a good way to specify that kind of alias, so for now,
take it out and replace the examples in the docs with the more verbose
equivalents.
refs: #2173
refs: #2296
Adjusts how mouse events are matched so that we can now indicate whether
mouse reporting and alt-screen should be considered as part of the event
trigger criteria.
refs: #2173
refs: #581
This doesn't really change any behavior, but adjusts the types
such that CSIs that set colors have the potential to track the
alpha channel and that can make it through to the GUI/render layer.
The recent work on the scrollback made it easier to constrain the
search region, so expose those parameters to the Pane::search
interface and to the mux protocol.
Use those new parameters to constrain quickselect search to
1000 rows above and below the current viewport by default, and
add a new parameter to QuickSelectArgs that allows overriding that
range.
A follow-up commit could make the search/copy overlay issue a series
of searches in chunks so that it avoids blocking the UI when
searching very large scrollback.
refs: https://github.com/wez/wezterm/pull/1317
Various color schemes have been duplicated as they have been added to
different scheme collections. They don't always have identical names
(eg: some remove spaces) and sometimes they have very different names
(eg: _bash vs. nightfox, or Miu vs. Blazer).
We already detected duplicates from different collections but previously
we would omit those dupes.
This commit allows us to track those duplicates by recording their
aliases.
When we write out our data, we only include "interesting" alias names;
those where the name isn't trivially identical.
Some scheme collections (eg: iterm2 color schemes) have duplicates
(eg: zenbones and zenbones_light are identical) and we have previously
shipped with both of those names, so we special case to emit dupes
for which we have prior version information in order to avoid
breaking backwards compatibility for our users.
In the doc generation we can generate links to the aliases if we
included them, but also note about the other names and how we don't
include them. That is so that someone searching the docs for say
"_bash" can discover that it is actually a duplicate of "nightfox" and
use nightfox instead.
This allows the hook to choose how to handle eg: `wezterm start -- top`.
Previously, if you had implemented this event you would essentially lose
the ability to specify a command that you wanted to launch.
refs: https://github.com/wez/wezterm/issues/284
I needed this while swinging through to the new color scheme data stuff,
but I don't need it any more, and it causes problems with external toml
files.
