The prior mutually exclusive behavior kept surprising people so let's
just flip this around.
This is potentially a "breaking" change for folks, but I think it is
worth it.
I was seeing a black "hole" in the center of this gradient:
```
background = {
{
source = {
Gradient={
colors = {"rgb(45,26,109)", "black"},
orientation = {
Radial={
cx = 0.75,
cy = 0.75,
radius = 1.25,
}
},
}
},
width="100%",
height="100%",
},
```
setting noise=0 "fixed" it, so this commit localizes that fix
to the center of the gradient by preventing noise from wrapping
around the gradient.
This breaking API change allows us to explicitly generate EOF when the
taken writer is dropped.
The examples have been updated to show how to manage read, write
and waiting without deadlock for both linux and windows.
Need to confirm that this is still good on macOS, but my
confidence is high.
I've also removed ssh2 support from this crate as part of this
change. We haven't used it directly in wezterm in a long while
and removing it from here means that there is slightly less code
to keep compiling over and over.
refs: https://github.com/wez/wezterm/discussions/2392
refs: https://github.com/wez/wezterm/issues/1396
Previously, we'd unconditionally enable dual source blending for the
text foreground layer when rendering. That meant that if the user had
configured the fg color to include an alpha value it would get "stamped
through" the draw all the way to the background, making that whole pixel
take on that alpha value rather than allowing it to blend through the
way you might expect.
In prior releases that didn't matter, but since we now allow configuring
the fg color with alpha, and allow using escape sequences to set the fg
for a span to something with alpha, there is now a much higher chance of
something looking weird.
Dual source blending is only really needed for subpixel-aa and that
isn't enabled by default.
This commit changes the behavior to use regular alpha blending if the
main config (rather than a per-font override) hasn't set the freetype
load/render target to one that enables subpixel-aa.
That means that alpha channel values work as expected for fg color
by default.
If you want to enable subpixel-aa you need to enable it globally
and be aware that it will cause weirdness when trying to use alpha
channels for the fg text color.
The docs now also indicate this behavior.
This limitation could be removed by making text rendering significantly
more complex and I don't fancy doing that at this time.
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
Allows the following assignment actions; I was just over-using z for
no real reason, I'm not suggesting that these are good assignments.
```
-- move the cursor backwards to the start of the current zone, or
-- to the prior zone if already at the start
{ key = 'z', mods = 'NONE', action = act.CopyMode 'MoveBackwardSemanticZone' },
-- move the cursor forwards to the start of the next zone
{ key = 'Z', mods = 'NONE', action = act.CopyMode 'MoveForwardSemanticZone' },
-- start selecting by zone: both the start point and the cursor
-- position will be expanded to the containing zone and the union
-- of those two will be used for the selection
{
key = 'z',
mods = 'CTRL',
action = act.CopyMode { SetSelectionMode = 'SemanticZone' },
},
-- like MoveBackwardSemanticZone by only considers zones of the
-- specified type
{ key = 'z', mods = 'ALT', action = act.CopyMode { MoveBackwardZoneOfType ='Output' }},
-- like MoveForwardSemanticZone by only considers zones of the
-- specified type
{ key = 'Z', mods = 'ALT', action = act.CopyMode { MoveForwardZoneOfType ='Output' }},
```
refs: https://github.com/wez/wezterm/issues/2346
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
Adjusts how mouse events are matched so that we can now indicate whether
mouse reporting and alt-screen should be considered as part of the event
trigger criteria.
refs: #2173
refs: #581
This doesn't really change any behavior, but adjusts the types
such that CSIs that set colors have the potential to track the
alpha channel and that can make it through to the GUI/render layer.
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
In order to avoid searching for "c", "ca", "cat" when typing "cat",
this commit introduces a hard-coded 350ms debounce.
refs: https://github.com/wez/wezterm/issues/1569
If you typed "cat" in the search, the chances are that wezterm
would kick off a search for "c" before you finished typing,
then "ca" and then finally "cat".
There was a race:
clear by_line highlights,
queue search for "c"
clear by_line highlights,
queue search for "ca"
clear by_line highlights,
queue search for "cat"
accumulate highlights for "c" into by_line
accumulate highlights for "ca" into by_line
accumulate highlights for "cat" into by_line
so the final result was a superposition of all of those results,
which was weird!
The fix is simple: clear by_line when we get the results of
an async search.
Adds the option to use an alternative clusted line storage for
the cells component of the line.
This structure is not optimal for mutation, but is better structured
for:
* matching/extracting textual content
* using less memory than the prior simple vector
For some contrast: the line "hello" occupies 5 Cells in the cell based
storage; that 5 discrete Cells each with their own tiny string
and a copy of their attributes.
The clustered version of the line stores one copy of the cell
attributes, the string "hello" and some small (almost constant size)
overhead for some metadata. For simple lines of ascii text, the
clustered version is smaller as there are fewer copies of the cell
attributes. Over the span of a large scrollback and typical terminal
display composition, this saving is anticipated to be significant.
The clustered version is also cheaper to search as it doesn't require
building a copy of the search text for each line (provided the line is
already in clustered form).
This commit introduces the capability: none of the internals request the
new form yet, and there are likely a few call sites that need to be
tweaked to avoid coersion from clustered to vector form.
We didn't actually update the global config, just the per-window
configs, which led to weird stale throwbacks to earlier versions
of the config when spawning windows or new panes.
Fix that up by explicitly reloading the global config when the
window appearance is changed. That isn't ideal as we will reload
once per window, but it's "OK".
While poking at this, I noticed that the get/set config methods
on the termwiztermtab overlay weren't hooked up, and also made
a point of calling those for any overlays during a window config
reload event, so that per-window overrides are more likely to get
picked up and respected.
refs: https://github.com/wez/wezterm/issues/2295
Need to explicitly pop it in front of the tab text layer so that
the button is physically rendered on top of the tab title.
refs: https://github.com/wez/wezterm/issues/2269
This allows the hook to choose how to handle eg: `wezterm start -- top`.
Previously, if you had implemented this event you would essentially lose
the ability to specify a command that you wanted to launch.
refs: https://github.com/wez/wezterm/issues/284
This simplifies the "change scheme based on dark mode" example
a lot. This was previously impossible to do because we didn't
have a lua module associated with the gui until recently, so
the only way to reference a gui-related object was via an
event callback.
refs: https://github.com/wez/wezterm/issues/2258
It can be confusing to see the same log lines when re-opening
the debug overlay, so this commit remembers the last line
in a global to make that feel more natural.
Because that causes the initial `OpenGL Initialized!` log to
show only in the first instance of the overlay, that log line
is now changed to debug level and the overlay will now
explicitly log the version information, along with some
brief usage text:
```
Debug Overlay
wezterm version: 20220714-001416-810512c2
OpenGL version: AMD BEIGE_GOBY (LLVM 14.0.0, DRM 3.46, 5.18.10-200.fc36.x86_64) 4.6 (Compatibility Profile) Mesa 22.1.3
Enter lua statements or expressions and hit Enter.
Press ESC or CTRL-D to exit
```
Attach the mux events to the frontend workspace reconciliation function
so that the window is updated to match the new workspace.
Ensure that we correctly clear out any overlay panes as part of the
switch: we need to remove them from the mux so that the mux will
correctly identify that the mux is empty when the main panes from
the workspace are closed. The problem case was that the debug overlay
state was forgotten by the gui when activating the new workspace, but
we didn't tell the mux to kill it off, so subsequently CTRL-D'ing
the windows closed the windows but left the wezterm process running with
no head.
refs: #2248
We don't really know which of the on-screen matches the user was
looking at when they selected the text, but assume that the one
nearest the bottom of the viewport is the one they want to select,
rather than the one closest to the top.
refs: https://github.com/wez/wezterm/issues/2250
