Using the newly exposed-to-lua mux apis, you may now run some lua code
at GUI startup and/or mux startup, just prior to any default windows
being created.
If you happen to spawn any panes as a result of this, wezterm will
skip creating the default program.
```lua
local wezterm = require 'wezterm'
local mux = wezterm.mux
-- This produces a window split horizontally into three equal parts
wezterm.on("gui-startup", function()
wezterm.log_info("doing gui startup")
local tab, pane, window = mux.spawn_window{}
mux.split_pane(pane, {size=0.3})
mux.split_pane(pane, {size=0.5})
end)
wezterm.on("mux-startup", function()
wezterm.log_info("doing mux startup")
local tab, pane, window = mux.spawn_window{}
mux.split_pane(pane, {size=0.5, direction="Top"})
end)
return {
unix_domains = {
{name="unix"}
},
}
```
refs: #674
refs: #1949
The intent is to expose Mux related functions to lua, so `wezterm.mux`
will be that module table.
In order to test this out in the debug overlay, I realized that the
overlay was running functions in a different thread and didn't have
access to the mux, so this commit also tweaks the debug overlay repl to
execute the input in the main thread.
The result is that it is now possible to do
`wezterm.mux.active_workspace()` in the debug overlay to print the
active workspace name.
More functions will follow.
refs: https://github.com/wez/wezterm/issues/225
Main thing to note here is that the open crate has deprecated
open::that_in_background, but made open::that non-blocking.
I think this is OK, but I'm a little cagey about what will
happen with this on Windows. We may need to spawn our own
thread for this if things go awry.
I did an ad-hoc test where I set the new tab button background to
an Animated value and saw that it eased in and out.
However, this commit doesn't make anything use this yet.
This is prep for future work where I'll be moving more of the main
monospace rendering into the box model code and factoring out
this aspect of animation.
Useful if you want to add smaller items to your background layers
every so often; you can specify the distance between them and make
it independent of the item height.
The color can have alpha and blend with other layers.
This is helpful if your image has fully transparent portions
and you want to explicitly place a color in there.
The `File` variant for background layers may now be an object
that specifes a speed factor. That factor is applied to the
animation frame durations in the loaded image, allowing the
playback rate to be adjusted.
Adjusts the background rendering logic so that we now allocate
a render layer for each defined background layer. This allows
their individual opacity value to multiple and blend together.
As part of this, I noticed that the big jpegs I was using could
take 400ms or more to load, so I added a basic cache to avoid
loading the same image multiple times around a config reload.
This adds some types that will enable richer background images.
* Can specify multiple layers
* Each layer can select from image files or gradient definitions
* Layers have additional properties to specify positioning, scaling,
tiling and whether they scroll with the viewport.
None of the additional properties are hooked up yet.
This commit allows for the SplitPane internal action to use the
pane id of an existing pane as the source of the pane to be added
in the new split target, rather than spawning a new command.
This can be used to move a pane from one tab to another, and is
analagous to tmux's `join-pane` command.
refs: https://github.com/wez/wezterm/discussions/2043
refs: https://github.com/wez/wezterm/issues/1253
Make the layer allocation more dynamic, which makes it
possible for the box model stuff to allocate a layer based
on the zindex for an element.
Adjust the box model code to cascade the base zindex via
the layer context so that the render stage can select
the correct layer.
This fixes up rendering tabs over the top of the right status
area.
Wraps up the changes from the following diff and allows for the modal
layer (and box model) to use alpha for poly quads.
Change the default background color for pane select to be slightly
transparent.
Each layer has the same 3-pass draw that we use for the main terminal
display.
These layers allow for potentially compositing between the layers.
That is untested at the moment as the upper layers use the box model
stuff which hard-codes its work to the vb index 1 which doesn't
use regular alpha blending.
This is still a bit of a WIP, but this commit:
* Introduces a new "Modal" concept to the GUI layer. The intent is
that modal intercepts key and mouse events while active, and renders
over the top of the rest of the normal display.
I think there might be a couple of cases where key events skirt
through this, but this is good enough as a first step.
Also, the render is forced into layer 1 which has some funny side
effects: if the modal choses to render transparent, it will poke
a hole in the window because all the rendering happens together:
there aren't distinct layer compositing passes.
* Add a new PaneSelect action that is implemented as a modal.
It uses quickselect style alphabet -> pane label generation and
renders the labels over ~the middle of each pane using an
enlarged version of the window frame font. Typing the label
will activate that pane. Escape will cancel the modal.
More styling and docs will follow in a later commit.
refs: #1975
This, along with the plumbing included here, allows specifying
the destination of the split (now you can specify top/left, whereas
previously it was limited to right/bottom), as well as the size
of the split, and also whether the split targets the node at the
top level of the tab rather than the active pane--that is referred
to as full-width in tmux terminology.
https://github.com/wez/wezterm/issues/578
Invalid option names, or values that evaluate as nil (such as the `foo`
above: that's treated as a global variable reference, but `foo` isn't a
defined global and evaluates as `nil`) will now cause the program
startup to error out with an actionable error message.
Previously, the invalid config name would generate a warning, and the
invalid value would silently have no effect as it has the same effect as
omitting the named value and leaving it as its default value.
I think these cases should both immediately error out and stop
further processing, so that's what we're doing.
This commit also adds support for adding:
```
#[dynamic(deprecated = "use newer option instead")]
pub some_config_value: bool,
```
but not options currently use this.
To do this, we split `Pattern` into the underlying pattern for the mux
layer (which is part of the codec), and another for the config layer,
so that we can specify this new mode.
At the gui layer, we translate the selection variant into the actual
selection text and map it to the mux Pattern enum.
When taking the selection text, we restrict it to just the first line.
refs: https://github.com/wez/wezterm/issues/1912
Turn on multi-line mode by default, and improve the localpane
search function to collapse runs of trailing whitespace into
just a newline.
That allows:
```
./target/debug/wezterm -n --config 'quick_select_patterns={"foo$"}'
```
to match the first line from this, but not the second:
```
printf "foo\nfoobar\n"
```
and this to match both:
```
./target/debug/wezterm -n --config 'quick_select_patterns={"^foo"}'
```
refs: https://github.com/wez/wezterm/issues/2008
Avoid using serde for mapping between Lua and Rust for the `Config`
struct.
This improves the build speed of the config crate by 2x; it goes down
from 30 seconds to 9 seconds on my 5950x.
fixes:
* beginning the selection with the top right or bottom left corner
* beginning the selection with the bottom right corner and only select a single line
The issue here was that we'd try to match this:
```
key_event RawKeyEvent { key: Char('t'), modifiers: ALT | LEFT_ALT, phys_code: Some(T), raw_code: 17, repeat_count: 1, key_is_down: true, handled: Handled(false) }
```
which has mods=`ALT|LEFT_ALT` against `ALT` and would fail.
We need to strip out the positional ALTs from the modifiers
in order to successfully match.
refs: https://github.com/wez/wezterm/issues/1958
This commit re-arranges the code so that an overlay can have a local
stack of key table activations; this allows copy_mode and search_mode
key tables to layer on top of the user's window level key tables.
Previously, we'd just stick the search_mode entry on top of the global
state, which worked, but had the undesirable side effect of hijacking
the Enter key when switching to another tab in the window.
refs: https://github.com/wez/wezterm/issues/993
The copy overlay now has a notion of running in search mode vs. copy
mode; it can be launched in either mode.
Search mode has a separate key table called `search_mode`.
Activating copy mode while search mode is active will now update
the mode of the existing overlay, rather than cancelling and creating
a new instance, and vice versa.
Activating copy mode while search mode is active will replace the
current key table activation (which is assumed to be `copy_mode`)
with `search_mode`, and vice versa.
The viewport is no longer scrolled to the bottom when activating search
mode.
refs: https://github.com/wez/wezterm/issues/993
refs: https://github.com/wez/wezterm/issues/1592
This change causes key table activations to effectively layer
over prior key table activations.
This is necessary for the copy mode key assignment changes to
work.
refs: https://github.com/wez/wezterm/issues/993
Moves the key handling in the copy overlay to be driven entirely
by configurable key assignments.
Note: copy mode wants you to use the `Copy` assignment to actually
do the copy, but this implementation hides the normal key assignments
by activating the copy mode key table. This will be addressed
in the following commit.
refs: https://github.com/wez/wezterm/issues/993
The launcher menu code to perform attaching has been generalized
into a key assignment action and reimplemented in terms of that
action.
A detach action has been added to disconnect and detach.
refs: https://github.com/wez/wezterm/issues/1874
If we had previously killed all the panes in a remote mux,
and then reconnected to it using the launcher menu attach option,
we could end up in a confusing state where we connect but don't
show anything for the remote; it looks like nothing happened
even though it is legitimately showing the empty remote mux.
This commit checks for that case and spawns the default program
in the remote if there are no panes.
This commit allows the currently active window to:
* Spawn a new tab in the active window (rather than spawning
a new window) to host the connection status
* Auto-close that connection UI tab (rather than the whole window)
when the window is no longer needed
* Pass the current window through to use as the primary window when
assigning remote window/tabs.
The net effect of this is that there are fewer transient windows,
and that it is easier to connect a set of domains to the active
workspace.
refs: https://github.com/wez/wezterm/issues/1874
When the screen is cleared/reset, the physical top is not reset with it,
instead the scrollback_top variable gets set with the point at which the
screen was reset / you are allowed to scroll back to. The scroll bar
code wasn't aware of that.
refs: https://github.com/wez/wezterm/issues/1866
