Skip to content

default color scheme: Make commands "normal" color#10758

Merged
faho merged 1 commit into
fish-shell:masterfrom
faho:defruitsalad-default-color
Oct 15, 2024
Merged

default color scheme: Make commands "normal" color#10758
faho merged 1 commit into
fish-shell:masterfrom
faho:defruitsalad-default-color

Conversation

@faho
Copy link
Copy Markdown
Member

@faho faho commented Oct 2, 2024

This makes the default colorscheme less colorful for two reasons:

  1. It makes it a little less "angry fruit salad"
  2. Some terminals (like Microsoft's Windows Terminal) have a terrible blue default that contrasts badly against a black background

The alternative is to make parameters "normal" and give commands the current parameter color (cyan). But I've seen cyan be quite blue and quite green depending on the terminal, so I don't want to rely on it.

Remember that our default theme uses 16 palette colors only and should work for light and dark terminals if at all possible.

Some screenshots in various terminals with the default color palette (konsole, kitty, gnome console IIRC, but I can't tell which is which) - the middle colorscheme is what I'm proposing, the last is the alternative:

Bildschirmfoto_20241002_161232
Bildschirmfoto_20241002_161316
Bildschirmfoto_20241002_161609

And in xterm:
Bildschirmfoto_20241002_183613

Notice how the blue in xterm is pretty hard to read, so any terminal that took its color palette will also be hard to read. Of course there are zero guarantees here, the terminal can use whichever colors it wants, but you'd be hard pressed to find a terminal that sets "normal" to unreadable on whatever background, and I'd be fine calling that a bug in that terminal.

I also believe that this makes the default colorscheme more pleasant simply by making it less busy.

TODOs:

  • [N/A] Changes to fish usage are reflected in user documentation/manpages.
  • [N/A] Tests have been added for regressions fixed
  • User-visible changes noted in CHANGELOG.rst

This makes the default colorscheme less colorful for two reasons:

1. It makes it a little less "angry fruit salad"
2. Some terminals (like Microsoft's Windows Terminal) have a terrible
blue default that contrasts badly against a black background

The alternative is to make *parameters* "normal" and give commands the
current parameter color (cyan). But I've seen cyan be quite blue and
quite green depending on the terminal, so I don't want to rely on it.
@faho faho added this to the fish 4.0 milestone Oct 2, 2024
@faho
Copy link
Copy Markdown
Member Author

faho commented Oct 3, 2024

Another problem we have is that the "quoted string" color is yellow, and that's often bad on a light background.

We could change that to green instead, which is already the "end" color (used for ; and &). Here's a screenshot on xterm:

Bildschirmfoto_20241003_121033

And on gnome console:

Bildschirmfoto_20241003_121104

Yes, this is a downside of the palette system, and a clear deficiency in these terminals' default palette. We can't, in general, always pick colors that are always visible everywhere. But these are fairly prominent terminals and we can try to make it acceptable more often.

@krobelus
Copy link
Copy Markdown
Contributor

krobelus commented Oct 5, 2024

We failed to implement something that tells us the difference between a uvar being the default color or user-set.
So the updates will fail to reach existing users. We should at least try to fix that for the future.

so I don't want to rely on it.

it's true that cyan varies but does that matter? It's always readable I think, so making parameters normal sounds
better to me (since there can be a lot of parameters).

The same problem with blue colors applies to ls.
We should report the problem to the affected terminals.

@chapmanjacobd
Copy link
Copy Markdown
Contributor

chapmanjacobd commented Oct 6, 2024

Screenshot_2024-10-06_2204 01

I like normal parameters as well. I've been using that in my color scheme for a while

bright yellow is unreadable in many terminals but green feels like too strong of a color for quoted. I don't think there should be much of a visual difference compared to parameters with escaped spaces because there is not much of a semantic difference... maybe purple would be closer to normal? or just use normal?

However, green might work well for autosuggestion. I've been using it that way since last night and it makes it much more obvious that it is an autosuggestion

@faho
Copy link
Copy Markdown
Member Author

faho commented Oct 8, 2024

So the updates will fail to reach existing users. We should at least try to fix that for the future.

In this case, that's entirely fine. Changing the colorscheme is easy enough, so if someone is sticking with the default they're okay with it, meaning there's no need to fix it for them.

so making parameters normal sounds
better to me (since there can be a lot of parameters).

That is a possibility, but many parameters won't be "param" color - they'll be quoted or error or redirections or whathaveyou.

So there's not as much difference as you think.

I think I prefer the smaller change of only changing the command/keyword color.

We should report the problem to the affected terminals.

Gonna be honest I have no faith in xterm changing its default palette.

maybe purple would be closer to normal?

We don't know how close "purple" is to "normal", especially given that "normal" can be anything from pure black to pure white.

(also canonically it's "magenta", we accept "purple" as an alias)

However, green might work well for autosuggestion

From what I can tell, there is currently no problem with the autosuggestion color, so I don't want to change it. Grey is the ideal choice there - we keep saying it is "greyed out".


One big problem here is that it is essentially impossible to make a good colorscheme with these constraints. We quite literally want it to work on white and black backgrounds and only have 16 colors to pick from that we do not even know.

So, since we can only really guess and try, I don't want to make too many changes here.

@krobelus
Copy link
Copy Markdown
Contributor

I didn't test it much but it sometimes feels a bit strange that command and non-special params are so different.

How about set -g fish_color_command cyan --bold?
(Or make them both normal but I guess that would be pretty un-fish-y)

Anyway, that's not a blocker, I'd be fine with this patch as-is.

So the updates will fail to reach existing users. We should at least try to fix that for the future.

In this case, that's entirely fine. Changing the colorscheme is easy enough, so if someone is sticking with the default they're okay with it. In that case there's no need to fix it for them.

No. People overwhelmingly stick to bad defaults even though they're easy to change. There's not enough time for that. It's our job. Fish is doing something very foolish here. Of course this is an unrelated issue.

We should report the problem to the affected terminals.

Gonna be honest I have no faith in xterm changing its default palette.

There are others like Windows Terminal, I'm sure they are interested in having readable ls --color=auto. I guess many terminals have a light colorscheme by default where it's not broken

@faho
Copy link
Copy Markdown
Member Author

faho commented Oct 15, 2024

Alright, let's merge this as-is, and see if we can find any improvements later.

@faho faho merged commit 81ff6db into fish-shell:master Oct 15, 2024
@faho faho deleted the defruitsalad-default-color branch October 15, 2024 19:24
@sebastianrasor
Copy link
Copy Markdown

Just gonna share my opinion as an end-user and not a maintainer, it was a little strange to me to install fish on a new machine for the first time in a while and see something different to what I've grown used to. Like it or not, I think that generally users tend to associate the default color scheme with the shell itself and while I wouldn't go so far as to say this change has made anybody distrust fish, it just feels like a weirdly unnecessary change to me at least.

Just my two cents though, obviously I can very easily just change those colors back to what they were

@github-actions github-actions Bot locked as resolved and limited conversation to collaborators Mar 16, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants