The renderer must track if the foreground, background, and cursor colors
are explicitly set by an OSC so that changes are not overridden when the
config file is reloaded.
Fixes: https://github.com/ghostty-org/ghostty/issues/2795
https://github.com/ghostty-org/ghostty/pull/3130 do over. Github seems
to have lost track of the fork status for the previous work. (perhaps
permissions?). Rebased the PR to main as I can't see why it could
possibly fail.
<details>
<summary>Previous description</summary>
Bit of a rabbit hole came up while trying to package ghostty for nixos.
zig build test would just hang when run as part of checkPhase in a nix
build. (rather than the nix develop ... command run in CI).
Here's what I understand so far:
/usr/bin/env does not exist in a nix build sandbox. This only works as a
test binary when running in nix develop as it shares its environment
with the user where this compatibility crutch exists.
When executing Command.zig tests that reference /usr/bin/env the
eventual call to fork+execevZ will duplicate the running test process as
execevZ returns rather than dissapearing into the new exec'd process.
Duplicating a test process via fork does unexepected things. zig build
test will hang for <reasons?>. A test binary created via -Demit-test-exe
will run two copies of the test suite producing two different failure
outputs for the same test. (or ~4 copies of the test framework, one
extra for each test that fails this way)
/bin/sh can be used and an alternative test target. It isn't amazing as
it's relying on stdenv creating /bin/sh and it just existing on user
systems. Other alternatives I can think of would require build flags or
some sort of contract with packaging around what binary will exist for
the Command.zig tests.
</details>
We refresh the link hover state in two (generic) cases
1. When the modifiers change
2. When the cursor changes position
Each of these have additional state qualifiers. Modify the qualifiers
such that we refresh links under the following scenarios:
1. Modifiers change
- Control is pressed (this is handled in the renderer)
- Mouse reporting is off
OR
Mouse reporting is on AND shift is pressed AND we are NOT reporting
shift to the terminal
2. Cursor changes position
- Control is pressed (this is handled in the renderer)
- We previously were over a link
- The position changed (or we had no previous position)
- Mouse reporting is off
OR
Mouse reporting is on AND shift is pressed AND we are NOT reporting
shift to the terminal
This fixes a few issues with the previous implementation:
1. If mouse reporting was on and you were over a link, pressing ctrl
would enable link hover state. If you moved your mouse, you would
exit that state. The logic in the keyCallback and the
cursorPosCallback was not the same. Now, they both check for the same
set of conditions
2. If mouse reporting was off, you could hold control and move the mouse
to discover links. If mouse reporting was on, holding control + shift
would not allow you to discover links. You had to be hovering one
when you pressed the modifiers. Previously, we only refreshed links
if we *weren't* reporting the mouse event. Now, we refresh links even
even if we report a mouse event (ie a mouse motion event with the
shift modifier pressed *will* hover links and also report events)
I realize I'm rolling the dice by opening a PR without a pre-approved
issue, but I'll take that chance. Feel free to close if this isn't
desired; no hard feelings!
Currently, the docs for `cursor-style-blink` have two backticks side by
side in the docs, which end up rendering as actual backticks rather than
a code-formatted blank space:
<img width="721" alt="Screenshot 2024-12-28 at 11 19 02 PM"
src="https://github.com/user-attachments/assets/295369d6-624f-4efe-a7ea-495c9fd216bb"
/>
This change puts a space between the backticks so they render as a
code-formatted space.
As a follow-up to #3477 and #3748, this eliminates the use of dlopen to
access `libX11` functions by directly linking `libX11` if X11 is
enabled. This should also fix problems with systems like NixOS and Void
Linux that have reported problems using Ghostty on X11 when using the
distribution packages.
This gives people finer-grained control over the coloring of their
window titlebars. Currently only implemented for GTK.
Signed-off-by: Tristan Partin <tristan@partin.io>
Fixes#3648
The confirm-close-surface configuration can now be set to always
ensuring a confirmation dialog is shown before closing a surface, even
if shell integration indicates no running processes.
The original version had issues converting properly and caused broken
glyphs. This version tries to be as simple as possible in order to make
it easy to understand. I haven't measured the performance but in
practice this will only happen during the first render of the glyph
after a face change (i.e. during launch or when changing font size).
Fix for misunderstanding in
https://github.com/ghostty-org/ghostty/issues/3400
Adds info about the MetricModifier config options that they can be used
with percentages, and links to the config option `adjust-cell-width`
that has more info
A few people were copying that snippet and were facing issues such as
"permission denied", and (after a subsequent `chmod`) "syntax error".
-----
From the [CONTRIBUTING.md]:
> Pull requests should be associated with a previously accepted issue.
I decided to ignore this for a single-word change, since creating a
discussion then waiting for it to be promoted to an issue seemed
pointless for such a minor change.
[CONTRIBUTING.md]:
https://github.com/ghostty-org/ghostty/blob/main/CONTRIBUTING.md#pull-requests-implement-an-issue
Based on both context and observed behavior, "now" was intended to be "not" in the paragraph describing the behavior of `focus-follows-mouse` is set to `true`.
