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.
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.
cc @jparise @anund @anmolw
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.*
I never got a response in the Discord server about PRing this so I
figured I would open the PR anyways.
I thought it might be a good idea to add this info into the README for
all the testers currently using Ghostty. I also think it might be a good
idea to have this in place before Ghostty goes public to potentially cut
down on the number of incoming requests for help and support regarding
configuration files and the inevitable duplicate requests for GUI
settings.
If this isn't something you'd like to add, feel free to close this. If
you want it adjusted in some way, let me know!
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.
Bash shell detection was originally disabled in #1823 due to problems
with /bin/bash on macOS.
Apple distributes their own patched version of Bash 3.2 on macOS that
disables the POSIX-style $ENV-based startup path:
e5397a7e74/bash-3.2/shell.c (L1112-L1114)
This means we're unable to perform our automatic shell integration
sequence in this specific environment. Standard Bash 3.2 works fine.
Knowing this, we can re-enable bash shell detection by default unless
we're running "/bin/bash" on Darwin. We can safely assume that's the
unsupported Bash executable because /bin is non-writable on modern macOS
installations due to System Integrity Protection.
macOS users can either manually source our shell integration script
(which otherwise works fine with Apple's Bash) or install a standard
version of Bash from Homebrew or elsewhere.
Bash shell detection was originally disabled in #1823 due to problems
with /bin/bash on macOS.
Apple distributes their own patched version of Bash 3.2 on macOS that
disables the POSIX-style $ENV-based startup path:
e5397a7e74/bash-3.2/shell.c (L1112-L1114)
This means we're unable to perform our automatic shell integration
sequence in this specific environment. Standard Bash 3.2 works fine.
Knowing this, we can re-enable bash shell detection by default unless
we're running "/bin/bash" on Darwin. We can safely assume that's the
unsupported Bash executable because /bin is non-writable on modern macOS
installations due to System Integrity Protection.
macOS users can either manually source our shell integration script
(which otherwise works fine with Apple's Bash) or install a standard
version of Bash from Homebrew or elsewhere.
