Not sure that this has any impact on us, as the changelog says
that the only change upstream was that glutin was updated.
We don't use glium with glutin, so probably a NOP?
On bash it's possible to hit ^C before we remembered the PS1 which would
cause the shell to end up with an empty PS1, making it unclear that the
^C actually worked as there is no prompt left.
I'm not sure I understand the need to mess with the variable every time
(could just add the OSC codes if not already present and never remove
them?), but at least make it so we don't end up with an empty prompt
line by checking the saved value isn't empty.
* Validate scrollback_lines to avoid crashes
I started using wezterm today, and I immediately tried to configure it
to use "infinite scrollback", as I use in iTerm2. From the configuration
I couldn't tell if there was a way to do this, so I just set it to a
really large number, hoping that would work. Interestingly this works
for very large numbers when the config is just being reloaded while the
terminal is running, but if you then try to restart the application it
crashes (tried to allocate like 100PB or something).
I then came across #1342 and thought "that's seems a bit too involved",
and decided that I probably don't need infinite scrollback, but just
kind of a large number. Through fair dice roll I determined `one billion - 1`
will probably suffice.
Now, this might not be the best solution, so I'm happy to get some feedback.
I was also thinking that it would be nice if one could just set it to `0`,
and then the applicatio determines a suitably large number for the amount of
RAM available, but a) I wasn't sure how this would be best implemented in the
confines of the current architecture, and b) I wasn't sure if it would be well
received.
Long story short, happy to hear your feedback.
* simplify slightly
---------
Co-authored-by: Wez Furlong <wez@wezfurlong.org>
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.
