-
-
Notifications
You must be signed in to change notification settings - Fork 760
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
starship git status icon (arrow up, arrow down) not rendering properly #5119
Comments
I'd suggest making a recording of what exactly is starship sending to the terminal using |
One guess: the starship line is bold red and the prompt is normal, so I would guess that's a difference which might explain the different rendering. What does (is there a way to make |
I've attached the recording (that's awesome, btw!) as well as the ls-fonts output. Perhaps you can spot something in there?! ls-fonts.txt Unicode 21e3 (that kind of arrow) doesn't seem to work. As a workaround I can use other arrows which are part of the nerd font. However, it would still be nice to find out what the problem is... |
I'm experiencing a similar issue as well on NixOS unstable, narrowing it down to the difference between the character being emitted by the prompt/shell vs stdout from other programs. For a minimum reproducible example, add |
Neither the |
Hi, thanks for your answer! Sorry for being imprecise! I do have a config and the ls-fonts is with the config. However, the same problem happens if I start wezterm using "wezterm -n" -- which from my understanding is without a config? I don't have access to the machine atm, so I can't provide my current config nor the ls-fonts from wezterm -n. |
I can confirm that the nix packaged version of wezterm includes the default font configuration, both by observing the fallback fonts running without a config as well as looking at the nix derivation. FWIW I ran a bisect against nixpkgs, NixOS/nixpkgs@700cec9 is where the behaviour changed. The referenced commit updated from |
Just FYI: I have a similar observation on mac: I do not configure any fonts and λ wezterm ls-fonts --text ⇕
LeftToRight
0 ⇕ \u{21d5} x_adv=8 cells=1 glyph=uni21D5,1924 wezterm.font("Menlo", {weight="Regular", stretch="Normal", style="Normal"})
/System/Library/Fonts/Menlo.ttc, CoreText Full wezterm ls-fonts outputλ wezterm ls-fonts
Primary font:
wezterm.font_with_fallback({
-- <built-in>, BuiltIn
"JetBrains Mono",
-- <built-in>, BuiltIn
-- Assumed to have Emoji Presentation
"Noto Color Emoji",
-- <built-in>, BuiltIn
"Symbols Nerd Font Mono",
})
When Intensity=Half Italic=true:
wezterm.font_with_fallback({
-- <built-in>, BuiltIn
-- AKA: "JetBrains Mono ExtraLight"
{family="JetBrains Mono", weight="ExtraLight", style="Italic"},
-- <built-in>, BuiltIn
"JetBrains Mono",
-- <built-in>, BuiltIn
-- Assumed to have Emoji Presentation
"Noto Color Emoji",
-- <built-in>, BuiltIn
"Symbols Nerd Font Mono",
})
When Intensity=Half Italic=false:
wezterm.font_with_fallback({
-- <built-in>, BuiltIn
{family="JetBrains Mono", weight="ExtraLight"},
-- <built-in>, BuiltIn
"JetBrains Mono",
-- <built-in>, BuiltIn
-- Assumed to have Emoji Presentation
"Noto Color Emoji",
-- <built-in>, BuiltIn
"Symbols Nerd Font Mono",
})
When Intensity=Bold Italic=false:
wezterm.font_with_fallback({
-- <built-in>, BuiltIn
{family="JetBrains Mono", weight="DemiBold"},
-- <built-in>, BuiltIn
"JetBrains Mono",
-- <built-in>, BuiltIn
-- Assumed to have Emoji Presentation
"Noto Color Emoji",
-- <built-in>, BuiltIn
"Symbols Nerd Font Mono",
})
When Intensity=Bold Italic=true:
wezterm.font_with_fallback({
-- <built-in>, BuiltIn
-- AKA: "JetBrains Mono SemiBold"
{family="JetBrains Mono", weight="DemiBold", style="Italic"},
-- <built-in>, BuiltIn
"JetBrains Mono",
-- <built-in>, BuiltIn
-- Assumed to have Emoji Presentation
"Noto Color Emoji",
-- <built-in>, BuiltIn
"Symbols Nerd Font Mono",
})
When Intensity=Normal Italic=true:
wezterm.font_with_fallback({
-- <built-in>, BuiltIn
{family="JetBrains Mono", style="Italic"},
-- <built-in>, BuiltIn
"JetBrains Mono",
-- <built-in>, BuiltIn
-- Assumed to have Emoji Presentation
"Noto Color Emoji",
-- <built-in>, BuiltIn
"Symbols Nerd Font Mono",
})
Title font:
wezterm.font_with_fallback({
-- <built-in>, BuiltIn
{family="Roboto", weight="Bold"},
-- <built-in>, BuiltIn
"JetBrains Mono",
-- <built-in>, BuiltIn
-- Assumed to have Emoji Presentation
"Noto Color Emoji",
-- <built-in>, BuiltIn
"Symbols Nerd Font Mono",
}) |
First, it's worth noting that most fonts do not contain every possible glyph. On all operating systems, if wezterm cannot find a glyph in the list of configured fonts, it will attempt to ask the system which font has it, using an OS-specific fallback. As a result it is expected to sometimes see fonts show up in What I'd like to nail down here is:
|
Hi wez! Attached you find files for the following:
Perhaps I wasn't precise: The missing glyph problem in the starship line is both present in a terminal with my config as well as in a terminal which I start with wezterm -n (without a config). Best regards and thank you for trying to solve this! fonts-with-21e3.txt |
What Operating System(s) are you seeing this problem on?
Linux Wayland
Which Wayland compositor or X11 Window manager(s) are you using?
Gnome
WezTerm version
20240203-110809-546fc22
Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?
No, and I'll explain why below
Describe the bug
Running on NixOS unstable.
Starship shows the git repo status in its prompt.
When the local repo is behind or ahead, an arrow is shown inside squared brackets. This arrow doesn't render correctly. However, if you copy/paste the missing symbol from the starship line to the prompt, it renders correctly.
(The arrow also renders correctly in both "Console" and "Kitty".
To Reproduce
The same happens without a config, e.g. "wezterm -n". Console and Kitty work fine.
Configuration
no config
Expected Behavior
Render up and down arrows correctly inside the squared brackets of starship.
Logs
No response
Anything else?
No response
The text was updated successfully, but these errors were encountered: