This is done with a wezterm twist: not only is the auth sock forwarded,
but the mux on the remote end will automatically maintain a symlink to
point to the auth sock of the most recently active mux client, and set
SSH_AUTH_SOCK to that symlink so that your remote panes should always be
referencing something sane.
refs: https://github.com/wez/wezterm/issues/1647
refs: https://github.com/wez/wezterm/discussions/988
This commit expands the set of data that we track for each client to
include the SSH_AUTH_SOCK. This defaults to the value of that env var on
the machine where the ClientId is constructed, which may be remote from
the mux server.
For the proxy scenario, a remote SSH_AUTH_SOCK path is not addressable,
and what we really want is the local SSH_AUTH_SOCK path from that SSH
session, so we introduce awareness of whether the current session is a
proxy session. Proxy sessions register the mux-local-proxy-id during the
setup of the proxy, but we don't apply the identity to the mux. Instead,
we wait for the remote client to send their identity and that is
annotate to show that it has been routed via a proxy and, crucially, has
the SSH_AUTH_SOCK replaced with the mux-local-proxy-id SSH_AUTH_SOCK.
```
; wezterm cli list-clients
USER HOST PID CONNECTED IDLE WORKSPACE FOCUS SSH_AUTH_SOCK
wez foo 336500 86.944834352s 944.834352ms default 3 /home/wez/.1password/agent.sock
wez foo (via proxy pid 337457) 337314 1.944834352s 944.834352ms 4 /tmp/ssh-XXXXTfGSp7/agent.337456
```
For the SSH_AUTH_SOCK to be populated, ssh agent forwarding also needs
to be enabled for SSH exec() calls; previously it was enabled only for
pty channels.
Since this commit changes the ABI of the mux protocol, the codec
version has been bumped.
This allows individual call sites to be able to force an immediate
resolution of the process information.
This should help to address https://github.com/wez/wezterm/issues/4811
wherein the problem seems to be that the cwd used for a new spawn
is taken from a stale read.
Relocate the helper function to mux-server-impl and have both the GUI
and the mux server call it at the appropriate times.
Introduce default_mux_server_domain which is used instead of
default_domain in the mux server. This is to avoid recursive
cycles when starting up the mux; we don't want the default
domain to be a unix client that connects to our selves because
we'll try to connect to ourselves, then in act of handling that
spawn in the default domain and try to connect to ourselves and
repeat.
refs: https://github.com/wez/wezterm/issues/3907
https://github.com/wez/wezterm/discussions/3480#discussioncomment-5567569
mentioned that running `wezterm cli spawn --domain-name SSH:foo`,
closing that tab and running `wezterm cli spawn --domain-name SSH:foo`
again failed.
The error message had no useful context.
This commit adds more context.
Previously, we'd record the focused pane only in the per-client
view.
That status didn't propagate through the model fully, leading to
inconsistencies when using activate-pane-direction.
This commit does the full model update to force that through.
I may regret this later: the focus state was intended to be
a per-client attribute and this effectively prevents that
from ever being useful.
Maybe the per-client state should just be removed?
Will ponder that later.
refs: https://github.com/wez/wezterm/issues/3448
refs: https://github.com/wez/wezterm/issues/3387
Also sneaking in here is not updating the last input time
for a client unless the input was taken by a user.
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
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 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
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.
* 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
Since the initial attach is async, we'd create the window at the
default/initial size and then never reconcile the size of the remote
tabs once they'd attached.
This commit introduces an event that allows the gui window to do that.
The action that it takes is to take the max width and height between
its current size and the size of a newly added tab and resizes to
that new size, if it changed.
refs: https://github.com/wez/wezterm/issues/2133
refs: https://github.com/wez/wezterm/issues/2351
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
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
Use some heuristics to verify the data that is about to be parsed;
this can help to detect eg: data being output to stdout prior
to us sending any encoded data to the remote mux.
In addition, add a timeout to help avoid waiting forever in
the case that we didn't detect a problem.
refs: https://github.com/wez/wezterm/issues/1860
Previously, we'd create a clipboard handler associated with a GUI window
and take care to pass that down to the underlying Pane whenever we
spawned a new pane.
For the mux server, instead of being associated with a GUI window, the
clipboard was a special RemoteClipboard that would send a PDU through
to the client that spawned the window.
The bug here was that when that client went away, the clipboard for
that window was broken.
If the mux server was the built-in mux in a gui process this could
leave a tab without working OSC 52 clipboard support.
This commit restructures things so that the Mux is responsible for
assigning a clipboard handler that rephrases the clipboard event
as a MuxNotification.
Both the GUI frontend and the mux server dispatcher already listen
for mux notifications and translate those events into appropriate
operations on the system clipboard or Pdus to send to the client(s).
refs: #1790
There were a a couple of issues:
* `ImageData::hash` would re-hash the image on every call, and this was
called for every cell that comprised an image on the mux server side
* `SerializedLine` needed to understand how to remove the `Arc<ImageData>`
image attachments so that we didn't serialize a complete copy of the
image per cell that comprised the image.
A new RPC was introduced to attempt to fetch `ImageData` given its
content hash and pane, row and cell index as a hint to locate it.
A client side LRU of content hash to `ImageData` is used to avoid
issuing repeat calls to that new RPC.
refs: #1237
wezterm cli spawn, and wezterm cli split-pane can use this information
to pick a default for the pane id when invoked from outside of wezterm.
refs: https://github.com/wez/wezterm/issues/1531
This commit does two related things, from opposite ends of the spectrum:
* Sets the sticky bit on pid files and unix sockets to avoid tmpwatch
deleting them in cleanup scenarios
* Falls back to looking at the changed time if the filesystem doesn't
support reporting creation time when wezterm does its own liveness
and cleanup checks for unix domain sockets in the runtime dir
* Allow any wezterm instance to perform that cleanup
refs: #1601
