When referencing the current-working-directory, before
it is set by an OSC 7 escape sequence, we ask the OS
for the correct path. This path was then being parsed
as a URL; where a "#" or "?" character would be
interpreted as the start of a fragment or query
component of a URL -- which is a mistake.
So this change parses the returned directory as such,
where those characters will be treated as a normal
character in the path.
Nothing is changed for the OSC 7 escape sequence case.
In that case, the application must percent-encode the
path before sending, so that those characters are not
misinterpreted.
As per issue #6158 reported by Syntaxheld
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>
