No colors in Warp terminal

[gthb]

Discord username (optional)

gthb

Describe the bug

difftastic output, produced with git difftool, configured in .gitconfig per these instructions, renders with no colors in Warp. Running the same command in Kitty gives me colors.

Losing the colors makes quite a difference for the usefulness of difftastic :-)

[EDIT: I've realized that I also have no colors in vim or in anything else — theme colors show, but terminal colors are monochrome in Warp for me.]

To Reproduce

Steps to reproduce:

1. Install difftastic: https://difftastic.wilfred.me.uk/installation.html
2. Configure it as your diff tool: https://difftastic.wilfred.me.uk/git.html
3. run git difftool HEAD^ in some repo
4. Note the lack of colors

(or just open vim on a syntax-highlightable file and :syntax on — in another terminal you'll see colors, in Warp it's black and white.)

Expected behaviour

I expect to see terminal colors.

Screenshots

In Warp:

In Kitty:

Operating System

MacOS

OS Version

12.4

Shell Version

zsh 5.8.1 (x86_64-apple-darwin21.0)

Warp Version

v0.2022.06.27.09.14.stable_01

Additional context

No response

Does this block you from using Warp daily?

~No~ ... well, doesn't exactly block me, but makes me disinclined. I switched back to Kitty because of this and #1428.

Warp Internal (ignore): linear-label:24888f54-df93-45d5-9bdd-e38f740cac19

No response

[gthb]

Sidenote: the bug template says:

Click the 3-dots menu docked to the right of the tabs in Warp and click the copy button,

but there is no copy button there (changed since the bug template was made, no doubt), just a very faint version string that's not copyable. Found the copyable one in the Settings dialog instead.

[elviskahoro]

Thanks for calling both of these out. Will update the bug template! I'll let u know once we have updates regarding the color

[elviskahoro]

@gthb does this still happen to you? Our team just tested and we're getting colored output.

[gthb]

Yes, still happens in latest release.

[elviskahoro]

@gthb I have the default settings from the installation documents and colors are working for me. Do colors work in your vim installation btw?

[elviskahoro]

@gthb also what version of warp are you using?

[gthb]

Colors do not work in my vim installation under Warp (and they do work under Kitty and iTerm2).

Warp version is v0.2022.09.07.14.56.stable_00 installed today —but same deal for newest version a few days ago

[gthb]

I ruled out anything in my ~/.zshrc and ~/.terminfo (the latter being a symlink to /Applications/kitty.app/Contents/Resources/kitty/terminfo) by renaming them away and starting a new terminal in Warp — no difference.

[gthb]

Edited title and description accordingly — Warp is not showing me any terminal colors. Apologies for the previous too-narrow title and description.

[elviskahoro]

@gthb do colors work in Vim if you run it like so:

vim -u NONE

[gthb]

No, it looks the same.

[warpdotdev-devx]

Can you check whether it’s something in your dotfiles by setting up clean configs: Set

ZDOTDIR=/

in your

~/.zshenv

file.

[gthb]

Can you check whether it’s something in your dotfiles by setting up clean configs:

Tried that. Same deal, all monochrome.

[jimwins]

I'm seeing almost the same problem on macOS 12.6 with v0.2022.09.20.08.08.stable_01.

What is strange is that the one bit of color I do get is the mode in the modeline in vim, but nothing else. I don't see colors from other programs like ls, too.

Attached screenshots are from running vim on a remote Linux box (Terminal vs. Warp), but the results are the same with running things locally, too.

(Terminal) (Warp)

[gthb]

In case it's any clue, I just noticed that when I switch to a light theme, the text is still rendered in white, only visible because the outlines are not all white (I guess because the antialiasing pixels are colored as if the text were black, or maybe as if the background were black), see screenshot:

[ckilb]

I just like to say that i have exactly the same issue. Once I installed Warp colors were working but after a few hours using it they disappeared. Now all the text is white.

And it keeps being white, even after

• restarting Warp
• rebooting MacOS
• changing theme
• removing warp.sqlite
• removing that number-only file in the same directory like warp.sqlite

Edit: It seems to be related to the chosen font in Preferences > Appearance. For most fonts, colors work. For Source Code Pro it doesn't work.

This is a serious bug because we all know that - even if Source Code Pro was once developed for Adobe - it's obviously the best font you can use in a terminal.

[gthb]

It seems to be related to the chosen font in Preferences > Appearance. For most fonts, colors work. For Source Code Pro it doesn't work.

Confirmed, I had that font configured, and switching to Menlo gives me colors.

[vorporeal]

Hm, I just tried to install Source Code Pro from Google Fonts (https://fonts.google.com/specimen/Source+Code+Pro) and can't reproduce the issue.

Could one of you share with me the font files you're using so I can try to repro on my end?

Also, are you running the latest version of Warp? Want to make sure it isn't something that's been fixed already.

[jimwins]

Just confirmed that it still happens with v0.2022.11.14.14.55.stable_01 and Source Code Pro downloaded from https://www.fontsquirrel.com/fonts/source-code-pro.

But it does work with the version downloaded from Google Fonts (both the variable and static fonts), and the OpenType version from here: https://github.com/adobe-fonts/source-code-pro/releases/tag/2.038R-ro%2F1.058R-it%2F1.018R-VAR

[jimwins]

Also works with the TrueType version from the Github project.

[RDStewart]

I didn't find this issue when looking earlier, so opened #1873. Turns out it's another manifestation of this one. When using a Source Code Pro which misbehaves, it's always white everywhere. This includes inside the "Terminal font", "Font size", and "Line height" fields. With lighter themes (especially Solarized Light), it gets impossible to read anything.

I installed Source Code Pro through Homebrew. Terminal.app is able to show colors with this same instance of Source Code Pro. After a quick brew uninstall font-source-code-pro; brew install font-source-code-pro, I now have working colors with Source Code Pro in Warp.

My day-job machine is still misbehaving, so I'll try to provide the instance of Source Code Pro from it.

[ckilb]

Hey,

I got the font from Github (https://github.com/adobe-fonts/source-code-pro). You can download it here: https://raw.githubusercontent.com/adobe-fonts/source-code-pro/release/TTF/SourceCodePro-Regular.ttf

[vorporeal]

@jimwins Thanks for that link; I'm able to repro with the version from Font Squirrel. Taking a look now to see what's going on.

[vorporeal]

In the meantime, as a workaround, try installing Source Code Pro again from a different source (e.g.: Google Fonts) - it seems only some copies of Source Code Pro have this issue.

[RDStewart]

On further investigation, this may be a known issue with Source Code Pro. Patched a few years ago, but I don't know of any tools which check to see if any of your fonts have available updates.

In case reproduction still matters, remove any installed instances of Source Code Pro. Download source-code-pro-2.030R-ro-1.050R-it.zip, unzip it, then move the contents of the OTF folder to ~/Library/Fonts/ and restart Warp.

It may be worth adding something to check for old version of Source Code Pro and warning the user. I'm not really sure how that would be accomplished, though.

[vorporeal]

Yeah, MacOS is reporting that the font uses pre-colored glyphs, a property which we respect (though perhaps we shouldn't).

I think there's not much we can do for now (aside from a warning to the user, which while a good idea, we probably won't get to for a little while).

[zmargeta]

Same issue with JuliaMono font, @vorporeal when might you change the behaviour related to pre-colored glypths if this is the case. No other terminal seems to do this. I installed the font with brew (font-juliamono)