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.
`wezterm start -- /etc/profile` would crash on macOS because
`/etc/profile` isn't executable.
This commit checks for executable access as a prereq for both the
path search and the absolute path cases and generates a non-crashing
error:
```
$ wezterm start -- /etc/profile
17:24:03.574 ERROR wezterm_gui > Unable to spawn /etc/profile because it doesn't exist on the filesystem or is not executable (EACCES: Permission denied); terminating
```
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
There was a race condition where we could leave the tab
active index pointing to the wrong pane.
That meant that the tab information computed by the gui
layer would see no panes marked as active, and thus would
end up with no active tab.
This commit fixes that by clamping the active index to
the number of panes.
refs: https://github.com/wez/wezterm/issues/2304
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
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
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
Otherwise we can block the gui waiting for eg: a freshly opened firefox to
terminate.
See also comment worrying about this in
75066cb522.
That fear was realized but now resolved!
refs: https://github.com/wez/wezterm/issues/2245
wezterm.color.parse() returns a color object that can be assigned in the
wezterm color config, and that can be used to adjust hue, saturation and
lightness, as well as calculate harmonizing colors (complements, triads,
squares) from the RGB/HSL color wheel.
