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.
This had a referencing issue, similar to the more recent GLOBALS
issue.
The resolution in this case is a lot simpler: we can just return
a regular lua table and use all the same underlying semantics,
but stick a metatable over the top to handle assignment and
provide the strict mode method.
If the target domain_id doesn't match the source pane.domain_id(),
then we consider the filesystem namespace to be incompatible and
won't try to use it.
refs: https://github.com/wez/wezterm/issues/3442
double-tapping the window title could lead to a cycle between
client and server.
The cycle is broken here by having the client defer advising
the server of a title change, and sending the now-current
title rather than the title embedded in the notification
from the mux layer.
refs: #1598
refs: #522
The termwiz Modifiers type isn't the right one!
Use the input layer types instead, and then we get the correct
string formatting.
refs: https://github.com/wez/wezterm/issues/3434
In the spawn initial mux case, we didn't verify that the mux
had no windows with the requested workspace, so we'd start up
with just the default session spawned by the mux when it starts
up.
This commit tries a bit harder to confirm that there is matching
domain/workspace combo before deciding that it is sufficient.
refs: #2734
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
In debug builds I noticed that sometimes we'd fail to connect
to a newly spawned unix server.
Increase the timeout to give it a chance to start up before
we error out.
Some of the `wezterm` subcommands (such as `wezterm
set-working-directory`) don't need the config at all
Loading the config can be relatively expensive and can slow
down those commands, so this commit defers loading the config
until a subcommand actually needs it.
refs: #3402
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
Finally getting around to wrapping this up; previously you had
to define your own format-tab-title event handler if you wanted
to show the title that you had set via `tab:set_title`.
Now, if that string is not empty, it will be used instead of
the title string from the active pane.
refs: #1598
The pixel sizes are too tiny on my retina mac display, so I wanted
to make them larger. I noticed that the background color was transparent
which resulted in the appearance of a cross behind the button; that's
due to the way that the rounded corners are applied, so we need to
explicitly fill the background with the same color.
Refactor to make changing the size in the future a DRY operation,
but I left the size as-is because it needs more finesse and
I want to come back to that tomorrow.
Remove an unsafe global variable and replace with a member variable
that works similarly to the drag tracking.
Doing this from a mac... may not compile on a windows box!
