There are situations where transient xcb errors can be generated
in regard to copy/paste selection. One example was reported
in connection with "wl-clip-persist" in issue #6128. And another
in issue #5482.
But there's no reason for us to terminate in response, so catch
and report any selection-related errors, as per code review in
PR #6135
* Restrict bell events to the proper window.
As per the comment in mod.rs, bell events are sent to
all windows; not just the window containing the pane
which generated the event.
To prevent each bell ringing multiple times, the window
event handler must check if it has the pane, and ignore
the bell event if it doesn't.
This fixes bug #5985
Co-authored-by: Sean Estabrooks <sean.estabrooks@eztux.com>
As per the documentation for the OutputState info method:
/// This may be none if the output has been destroyed or the
/// compositor has not sent information about the output yet.
Unwrapping its return has lead to crashes at startup, which to
the user can appear as WezTerm refusing to start.
This crate references features that were not defined in Cargo.toml.
Add those features, even though we don't use them, so that we are
not warned to death and don't drown in the noise.
I never liked clippy for dropping turds like this throughout the
code. I'm glad it is no longer required, but now rust is warning
about this syntax being redundant.
* Add a CloseWithoutClear copy mode key assignment
Closing the copy overlay currently unconditionally clears the viewport,
in particular resetting scroll. For the search overlay, we don't
necessarily want to scroll back to the prompt after finding a match --
indeed, the old search overlay (which didn't use copy mode) had this
behaviour.
Add a CloseWithoutClear key assignment which has this desired behaviour,
and make it the default for ESC in search mode.
* Change CloseWithoutClear into normal Close, and add ResetViewport
* Remove ResetViewport, add helper for keys
To avoid the following warning while using `lib.getExe`:
```
warning: getExe: Package wezterm does not have the meta.mainProgram attribute. We'll assume that the main program has the same name for now, but this behavior is deprecated, because it leads to surprising errors when the assumption does not hold. If the package has a main program, please set `meta.mainProgram` in its definition to make this warning go away. Otherwise, if the package does not have a main program, or if you don't control its definition, use getExe' to specify the name to the program, such as lib.getExe' foo "bar".
```
The implementation of this is a bit gnarly, because we have
an optional value with a default that *is* populated by the
dynamic config stuff, but that isn't part of the derive(Debug)
impl.
closes: https://github.com/wez/wezterm/issues/5547
The wrapper struct ensures ensures the child process spawned for
the ProxyCommand is cleaned up under all the various error scenarios
(such as auth failures etc), as well as in the normal successful use
case. This includes killing it if necessary, and then waiting for it.
Centralize the thread local state management into the selector module
to make it a bit more convenient to consume from the various other
locations.
closes: https://github.com/wez/wezterm/issues/5532
This has more intuitive sorting; eg: `line` used to show the first match
as `linux_endeavour` but now matches `LINEAR B IDEOGRAM VESSEL B212`
first, which feels more relevant (has an exact prefix match).
refs: https://github.com/wez/wezterm/issues/5532
