Introduce a setting allowing to customize the behavior of the quick terminal
when it loses focus. By default, the quick terminal will automatically hide.
However, you can now configure it to remain open by setting
`quick-terminal-autohide: false`.
Resolves#2558
We used a mix of shorthand and octal representations when printing these
control characters. Standardize on the shorter, more readable shorthand
notation because that's what we use in the other shell integration
scripts.
We used a mix of shorthand and octal representations when printing these
control characters. Standardize on the shorter, more readable shorthand
notation because that's what we use in the other shell integration
scripts.
When outside the viewport, other actions such as scrolling might be
happening, and doing an early return when clearing hyperlinks prevents
scrolling upwards.
We reposition the check, and do not early return so we can process
scrolling when it happens.
This fixes#2645, restoring the ability to scroll upwards while
retaining the behavior of hyperlinks when outside the viewport.
(and, yes I still permit my commits to be relicensed to MIT)
## Before
[Screen Recording 2024-12-21 at
01.36.02.webm](https://github.com/user-attachments/assets/bf144455-ff26-4d4e-9eff-c3d632c02c17)
## After
[Screen Recording 2024-12-21 at
01.36.44.webm](https://github.com/user-attachments/assets/308a795f-971d-4807-b4ba-91bd3685c185)
Given https://github.com/ghostty-org/ghostty/discussions/2994 revert
f1728f594a.
Add documentation to help point people towards the discussion and needed
changes to handle `COMP_WORDBREAKS` not including expected characters.
We know macOS and nixos defaults to including `=` so explicit handling
to change behaviour should only be required if it turns out some
systematically used tool brings in a completion function that changes
`COMP_WORDBREAKS` away from the default. (something they should not be
doing)
If necessary I can create a issue to track handling unexpected word
breaks usage. This change improves the current completions.
I agree to re-license my commits to MIT
Ghostty now has a release channel build configuration. Current valid
values are "tip" and "stable" but I imagine more will be added in the
future.
The release channel is inferred whether the version we specify with the
`-Dversion-string` build flag has a prerelease tag or not. If it does,
the release channel is "tip". If it doesn't, the release channel is
"stable".
This also adds a configuration to specify the release channel for
auto-updates for the macOS application.
When outside the viewport, other actions such as scrolling might be happening, and doing an early return when clearing hyperlinks prevents scrolling upwards.
We do not early return so we can process scrolling when it happens.
`std.fs.accessAbsolute` asserts if the user proposed path is absolute,
which we are seemingly passing as-is with no validating that it is.
When running with safety checks on, passing non-absolute path to
--working-directory will make ghostty crash.
I changed it to use `Dir.access`, which is just `accessAbsolute` without
the check.
This has the side effect of also allowing relative working directory.
The [fixterms](http://www.leonerd.org.uk/hacks/fixterms/) "Really
Special Keypresses" section suggests using CSI 1 ; Ps R for F3, but this
is also a valid cursor position report. The intention was to make
back-compatible changes, so this is fairly considered a specification
bug.
This changes F3 in legacy mode to send CSI 13 ; Ps ~ instead, this is a
variant listed in fixterms, is what kitty protocol uses, and lacks the
problematic overlap with cursor positions.
The KeyEncoder.zig unit test has been changed accordingly, and all tests
pass on my machine.
`std.fs.accessAbsolute` asserts if the user proposed path is absolute,
which we are seemingly passing as-is with no validating that it is.
When running with safety checks on, passing non-absolute path to
--working-directory will make ghostty crash.
I changed it to use `Dir.access`, which is just `accessAbsolute` without
the check.
This has the side effect of also allowing relative working directory.
The [fixterms](http://www.leonerd.org.uk/hacks/fixterms/) "Really
Special Keypresses" section suggests using CSI 1 ; Ps R for F3, but this
is also a valid cursor position report. The intention was to make back-
compatible changes, so this is fairly considered a specification bug.
This changes F3 in legacy mode to send CSI 13 ; Ps ~ instead, this is a
variant listed in fixterms, is what kitty protocol uses, and lacks the
problematic overlap with cursor positions.
The KeyEncoder.zig unit test has been changed accordingly, and all tests
pass on my machine.
The comment in `function_keys.zig` was missing the `>` character for the
sequence. I've confirmed that this was just the comment, Ghostty treats
the original as an SGR sequence, which it is. Conversely, it does treat
`\x1b[>4;2m` as activating modifyOtherKeys.
The comment in `function_keys.zig` was missing the `>` character for the
sequence. I've confirmed that this was just the comment, Ghostty treats
the original as an SGR sequence, which it is. Conversely, it does treat
`\x1b[>4:2m` as activating modifyOtherKeys.
- Simplifies and clarifies the math for how the bounding box for
rendered glyphs is computed
- Reduces margin from 2px between glyphs to 1px by only padding the
bottom and right side of each glyph
- Avoids excessive padding to glyph box when font thicken is enabled or
when using a synthetic bold (it was previously 4x as much padding as
necessary in some cases)
There is no reason to and I do not know where this assumption came from.
It's very possible for a colored glyph to (intentionally!) exceed the
cell bounds, and we shouldn't be stopping this...
Bash doesn't redraw the leading lines in a multiline prompt so we mark
the last line as a secondary prompt (k=s) to prevent the preceding lines
from being erased by Ghostty after a resize.
Our previously attempt at this (#1973) was flawed. Instead, we now just
re-issue the OSC "133;A" command with a 'k=s' (secondary) kind at the
end of our prompt string.
This isn't a great solution because it stomps on the prompt's "133;B"
command (end of prompt and start of user input), but it's sufficient for
now and only applies in the multiline prompt case.
Going forward, we should revisit our semantic prompt implementation. Our
row-based approach is too limiting; lines can have multiple markers, and
markers should be recorded with their full coordinates so they can form
ranges.
See: https://per.bothner.com/blog/2019/shell-integration-proposal/Fixes: #1961
Bash doesn't redraw the leading lines in a multiline prompt so we mark
the last line as a secondary prompt (k=s) to prevent the preceding lines
from being erased by Ghostty after a resize.
Our previously attempt at this (#1973) was flawed. Instead, we now just
re-issue the OSC "133;A" command with a 'k=s' (secondary) kind at the
end of our prompt string.
This isn't a great solution because it stomps on the prompt's "133;B"
command (end of prompt and start of user input), but it's sufficient for
now and only applies in the multiline prompt case.
Going forward, we should revisit our semantic prompt implementation. Our
row-based approach is too limiting; lines can have multiple markers, and
markers should be recorded with their full coordinates so they can form
ranges.
See: https://per.bothner.com/blog/2019/shell-integration-proposal/
This prevents forcibly injecting any configured shell integration into
the command's environment. Automatic shell detection is enabled, unless
shell integration has been explicitly disabled.
Our semantic prompts are row-based, so the last prompt marker set on a
row "wins". In the case of at least our bash shell integration, this
means that consecutive prompt lines will all be marked as .input (OSC
133;B -- end-of-prompt, start of input).
Previously, clearPrompt() identified the current prompt's "area" by
searching upward from the current row until it encounters a .prompt
marker or some command output. In the bash case, .prompt is never the
dominant ("last") marker, so clearPrompt() would aggressively clear all
immediately preceding consecutive prompts.
With this change, we'll stop searching upwards when we encounter some
command output, a .prompt marker, _or another .input marker_. That last
case prevents clearPrompt() from unintentionally clearing earlier prompt
lines.
There may be improvements we can make to the way that our bash shell
integration emits semantic prompt markers, but I think this logic is
generally sound for all cases, and it specifically improves the current
bash prompt-clearing experience.
---
Before and after, after resizing the terminal window to trigger a
reflow:
<img width="504"
src="https://github.com/user-attachments/assets/91aa652e-e262-445a-8eed-7268c0d66428"
/>
<img width="510"
src="https://github.com/user-attachments/assets/b43e0aa4-0e24-4f4e-9b2c-b6b07c8f8c77"
/>
Our semantic prompts are row-based, so the last prompt marker set on a
row "wins". In the case of at least our bash shell integration, this
means that consecutive prompt lines will all be marked as .input (OSC
133;B -- end-of-prompt, start of input).
Previously, clearPrompt() identified the current prompt's "area" by
searching upward from the current row until it encounters a .prompt
marker or some command output. In the bash case, .prompt is never the
dominant ("last") marker, so clearPrompt() would aggressively clear all
immediately preceding consecutive prompts.
With this change, we'll stop searching upwards when we encounter some
command output, a .prompt marker, _or another .input marker_. That last
case prevents clearPrompt() from unintentionally clearing earlier prompt
lines.
There may be improvements we can make to the way that our bash shell
integration emits semantic prompt markers, but I think this logic is
generally sound for all cases, and it specifically improves the current
bash prompt-clearing experience.
A typo in the fish completions (that was likely copied to the zsh and
bash completions) prevented CLI actions from using enums as option
values because the completions tried to access non-existent fields from
type introspection. This doesn't cause any problems _now_ because no CLI
action uses an enum as an option value. However as soon as you try and
add one the completions fail to compile.
This patch fixes the incorrect field reference. It also adds the ability
to have _optional_ enums as option values.
It turns out this happens more than I thought. Most notably, apple's
fallback font for a bunch of symbols, `Apple Gothic`, has no OS/2 table
🙃. I've gone ahead and fixed it so that both CoreText and FreeType
handle this gracefully.
Speaking of graceful handling, this problem came to attention due to our
very *un*-graceful handling of when a font fails to load due to a
metrics calculation error. It results in a bunch of blanked out text,
very bad, we should fix that.
*At some point I'll try to collect a group of test fonts with all sorts
of weirdnesses to exercise the weird edge cases in our handling.*
We're packaging more and more application-specific data directories in
our application bundle. It's helpful to add that path to XDG_DATA_DIRS
so those applications (that support XDG_DATA_DIRS) can locate their data
directories without additional user-level configuration.
This also fixes a typo ("MATHPATH") in the nearby MANPATH-building code.
We're packaging more and more application-specific data directories in
our application bundle. It's helpful to add that path to XDG_DATA_DIRS
so those applications (that support XDG_DATA_DIRS) can locate their data
directories without additional user-level configuration.
This also fixes a typo ("MATHPATH") in the nearby MANPATH-building code.
