Left a FIXME where the "Copy" button action is disabled.
Though very hackish this was the best way I found to do this currently.
Disable sensitivity on the button didn't do anything and trying to
remove the button altogether like on macOS, causes the menu to become
really buggy. Either by the context menu turning into a scrollable list
or by it becoming really janky and showing the user pre-update UI.
Two bugs:
1. If our pin is the top page, and self.y == top.y, then x will tell us
the answer. Before, we'd fall through.
2. If our pin is not the top or bottom, but the top == bottom, then we
can't possibly be between. Before, we'd incorrectly check the linked
list starting AFTER top.
These OSC 133 semantic prompt sequences mark the primary and secondary
parts of the prompt strings.
PS1 is marked as the primary (initial) prompt. This is the default, so
we could skip emitting these sequences, but they're added here for now
to be explicit and consistent with what other terminal emulators do in
their shell integrations.
If PS1 is a multiline prompt (i.e. it contains a newline), we mark the
last line as a secondary prompt (k=s). bash doesn't redraw the leading
lines of a multiline prompt on its own, so we can use this information
at runtime to prevent the preceding lines from being erased by ghostty
after a resize.
PS2 is always marked as a secondary prompt.
Quoting `man man`:
> If MANPATH begins with a colon, it is appended to the default list;
Alternatively we can think about:
> if it ends with a colon, it is prepended to the default list;
To take preference over existing values, but that shouldn't be really a
problem, as there rather isn't much of another projects named `ghostty`.
In b7699b9a, mouse shape functionality was moved from the GL area widget
to the overlay that was newly created for the URL target information
that was included as part of #1928. This seems to have the side effect
of causing the pointer shape to revert to the default shape (here, the
basic arrow pointer) when dragging the mouse during selections.
This moves it back to the GL area, which seems to correct this. It
doesn't seem to need to be added to both - everything seems to function
correctly when a link is moused over, and then selection is made down to
the overlay area (not that this scenario is very likely, though).
OSC 133 defines distinct continuation (c) and secondary (s) prompt
kinds. They're both treated as prompt continuations but have different
semantic meanings: `c` allows the user to "go back" and edit previous
lines, while `s` does not.
We don't (yet) handle this "editable" distinction, but this change makes
our OSC parser slightly more correct.
This is a quality of life UX change. font-family is a repeatable
configuration where each subsequent value will be added as a fallback
font.
This introduces a UX gotcha where if a font was set in a config file,
the CLI args (which are loaded later) would _append_ to the font
families. This has never once been the behavior I've wanted. Previously,
you'd have to do `--font-family=""` which is clunky.
This change makes it so that CLI font-family flags will automatically
clear the families set in the configuration file.
`gtk-single-instance` should already be doing desktop-only detection and
in most cases it does. But there are some cases where it isn't and we
haven't quite tracked it down yet.
In any case, when `-e` is used from the CLI, we definitely do not want
to launch in single instance mode because `-e` is typically used in
scripts or for one-off instances. This forces gtk-single-instance to
false.
