For whatever reason, it appears as though the wayland
frame event stuff is unreliable when used with webgpu,
so we simply avoid using it.
refs: https://github.com/wez/wezterm/issues/3126
These conditions were from the earliest days of panes and aren't
needed any more, especially because they make it hard to have
consistent behavior!
refs: https://github.com/wez/wezterm/issues/3450
I think the future for this is to extend the Pattern type to accept
a list of regexes and use a RegexSet to unambiguously handle multiple
patterns with captures.
That might help a little with https://github.com/wez/wezterm/issues/3247
but the stated use in that issue may not even work with the rust
regex crate.
For now we do the simple thing and match the user's patterns
first.
refs: https://github.com/wez/wezterm/issues/3456
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
