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
Work harder to notice and handle the PaneRemoved notification
more centrally, which allows removing some earlier workarounds.
Now when we receive PaneRemoved, we take the opportunity to handle
missing mapping or stale mapping between local and remote ids and
perform a resync before continuing to handle the PaneRemoved message.
Doing it this way means that we don't need to second guess the timing
of notification or the resync, so we end up with the correct sequence
of notifications, and the result is the correct size of the splits
because the local and remote aren't independently managing the
the pane removal with conflicting ideas of the new size.
refs: https://github.com/wez/wezterm/issues/3386
Three issues:
* The initial connect would leave the dpi assigned to 0, resulting
in incorrect scaling when using imgcat until the window was resized
and the correct dpi was passed up.
* On resize, we'd only compare the row/col count and not notice changes
in pixel dimensions/dpi
* On the server side, when processing a resize and recomputing
the tab size, we would omit the pixel dimensions and leave
the resulting tabs and panes with 0 dimensions, breaking imgcat
because it thought the window was 0x0.
refs: https://github.com/wez/wezterm/issues/3366
This commit causes the mux to generate a PaneFocused notification
when the active pane is changed.
The mux server will forward that as a unilateral PDU to connected
clients.
The clientpane implementation will handle that by applying the
same state to the local mux.
refs: #2863
* Translate from File to EncodedFile as needed
* Adopt blob leases in the mux server
* Fix an issue where the first image sent by the mux server would
be replaced on the client by its background image, if configured.
Removed the ImageData::id field to resolve this: you should use
the hash field instead to identify and disambiguate images.
Bumped the termwiz API version because this is conceptually
a breaking change to the API
refs: https://github.com/wez/wezterm/issues/3343
- 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.
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
This allows removing a bunch of unwrap/expect calls.
However, my primary motive was to replace the cases where we used
Mux::get() == None to indicate that we were not on the main thread.
A separate API has been added to test for that explicitly rather than
implicitly.
We weren't matching the domain id when resolving the remote->local pane
mapping, which meant that having 2 or more mux client domains active
would lead to associating eg: remote pane id 1 with whichever local
pane was associated with any remote pane id 1 *first*.
This commit requires that both the domain id and the remote pane id
match.
refs: https://github.com/wez/wezterm/issues/2616
When closing the all mux tabs in a window, the remote will close
the window. If the local has a mixture of local and remote tabs
then subsequent attempts to spawn a tab in that window would
fail due to reusing the stale remote window id.
This commit purges the local/remote mappings that are (probably)
dead when the remote indicates that a pane has been removed.
The mapping should be re-established as needed later on.
refs: https://github.com/wez/wezterm/issues/2614
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
The idea here is that different kinds of panes may want to expose
additional metadata to lua scripts. It would be a bit weird to add
a Pane method for each of those and plumb it all the way through
the various APIs, so just allowing a pane impl to return a dynamic
value (likely an Object) allows a bunch of flexibility.
This commit exposes the clientpane is_tardy boolean and the time
since the last data was recevied (since_last_response_ms) from
the mux client pane implementation: these are used to show the
tardiness indicator in the client pane.
Exposing this data enables the user to add that info to their
status bar if they wish.
Tidy some things up to avoid some dead code and redundant impls.
Make it easier to select whether you want to implement the new
methods in terms of the old, or the old methods in terms of
the new in a given pane impl.
Adds Pane::for_each_logical_line_in_stable_range_mut and
Pane::with_lines_mut which allow iterating mutably over lines.
The idea is that this will allow the renderer to directly cache
data in the Line via its appdata without having to build cumbersome
external caching logic and managing cache keys.
This commit just swaps the implementation around for localpane
and sanity checks that the renderer functions.
Various overlays and the mux client don't properly implement these
yet and current warn at compile time and panic at runtime.
To follow is the logic to cache the data and make sure that it
works the way that I think before converting the other Pane
implementations.
It didn't really belong there; it was added as a bit of a hack
to propagate screen reverse video mode.
Move that to the RenderableDims struct and remove the related
bits from Line
This makes those fields usable in `wezterm cli list --format json`.
This doesn't change the ABI of the mux protocol, but prior to
this commit, those fields were always 0.
refs: #2319
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
The previous commit added the option to convert the storage to
the cluster format. That saves memory as rows are moved to scrollback,
but makes scrolling back more expensive due to that conversion.
This commit adds a fast(ish) path for the common case of simply
appending text to a new line before it gets scrolled: the default
format for lines in the screen is now the cluster format and,
provided that the cursor moves from left to right as text is
emitted, can simply append to the cluster storage in-place
and avoids a conversion when the line is moved to scrollback.
This improves the throughput of `time cat enwiki8.wiki` so
that the runtime is typically around 11-12s (compared to 9-10s
before introducing cluster storage). However, this is often
a deal of variance in the measured time and I believe that
that is due to the renderer triggering conversions back to
the vec storage and introducing slowdowns from the render side.
That's what I'll investigate next.
The fixup callback can now by async, which makes it possible to use
other async functions in the callback.
There is an additional parameter to wezterm.exec_domain that allows
setting the label that is shown in the launcher menu.
It accepts either a string value or an async callback function
that can be used to compute the label dynamically.
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
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
The logic that figures out whether/how to map remote windows
to the potential local window needs to account for the workspaces
on any given local/remote pair.
In particular, if we are called with a primary window id that
has say "default" as its workspace, we mustn't decide to place
remote tabs from a window whose workspace is not "default"
into that local window, or else we can end up in a weird
state where we have 3 workspaces on the remote, but have
accidentally folded one of them into the `default` workspace
and thus end up thinking that we have one workspace with two
windows and one other workspace, instead of the intended
3 windows each with a distinct workspace.
refs: https://github.com/wez/wezterm/issues/1978
We need to notice when all of the streams associated with a channel are
closed and remove the channel from the set that we're polling in the
main loop, to avoid continually polling the closed descriptors.
Additionally, if the Session has been dropped, we know that we cannot
be asked to create any new channels, so if there are no more channels
then we can and should exit that dispatch loop and allow the resources
to be cleaned up.
refs: https://github.com/wez/wezterm/issues/1993#issuecomment-1130539934
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
