Allows prompting the user to select from a list and then
triggering some action on the selected item.
This is the guts of the launcher menu hooked up to user-supplied
arbitrary entries.
I dug out my pixelbook which has intel graphics and runs linux
to try to make sense of this issue, but I'm baffled.
It doesn't appear to NaN going in, but we end up with something
weird happening if we don't fixup the alpha.
Relevant entry to the discussion/background on this is:
https://github.com/wez/wezterm/issues/1180#issuecomment-1496102764
I don't think it's worth sweating over this, so let's just suck it
up.
refs: https://github.com/wez/wezterm/issues/1180
* character select pgup/down support for bigger jumps
* fix jerky selected_row clamping, keeps selected center offset
* die dead code
Co-authored-by: Wez Furlong <wez@wezfurlong.org>
* thx silly rustisms
Co-authored-by: Wez Furlong <wez@wezfurlong.org>
* charselect movements now spcified by amount, or 0 which does full pgsz
* rustfmt
---------
Co-authored-by: Wez Furlong <wez@wezfurlong.org>
is_active is true if the pane is considered to be the active pane
within its containing tab.
If you want to reason about the focused pane regardless of tab,
`wezterm cli list-clients` has that pane_id.
refs: https://github.com/wez/wezterm/issues/3413
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
