Nevermind, I found a solution:

ZSH_HIGHLIGHT_STYLES[comment]='none'

Comments are highlighted in gray. Your terminal's colour scheme may be out of tune.

Your terminal's colour scheme

Terminology with solarized-light theme.

Comments are highlighted in gray

Thank you.

@danielshahaf Isn't it hard coded as black?

Any string starting with a # or $ is completely invisible.

For # it'll be because INTERACTIVE_COMMENTS is set.

For $, things like $foo ls -l, where $foo would be elided, highlight $foo as a comment would be highlighted. The remainder of the line would be highlighted normally.

I tested in many different terminals with their built in theme. Only iTerm2 shows grayish color.

It shows as grey in a plain xterm and libvte, at least.

I also tried ssh to a ubuntu server

The color codes are decided by the terminal emulator running locally. ssh'ing wouldn't affect the outcome at all, unless the remote box generates different escape sequences than the local box.

You haven't proposed an alternative.

See also #780 and #739.

I tried xterm on my mac through a x server. It also shows as black. But it's mac. I could be wrong.
My proposal:
Ideally, you can query the background color from terminal and assign a color with reasonable contrast.
At least, you can set it to a gray color, instead of black. After searching the issues, I set ZSH_HIGHLIGHT_STYLES[comment]=fg=245. This can be set as the default.

BTW, I know ssh should not make a difference. I just find that INTERACTIVE_COMMENTS is unset by default on the remote machine.

Ideally, you can query the background color from terminal and assign a color with reasonable contrast.

Well, maybe. Or maybe those terminals that use the same colour values for "bold black" and "background" are buggy. If they use TERM=xterm, I'd argue they are, because xterm itself doesn't do that.

At least, you can set it to a gray color, instead of black. After searching the issues, I set ZSH_HIGHLIGHT_STYLES[comment]=fg=245. This can be set as the default.

Hmm. Interesting. First, can we assume the terminal supports 256 colours, or do we need to check this, and if so, how to check this portably? Second, do all supported zsh versions support 256-colour values in the colour specification syntax?

Reopening. Thoughts, anyone?

• Use brightened color for bold is a feature, that can be disabled. I'm not sure if it's the default, or all terminals support that. I would rather not assume all terminals have this feature.
• I assumed most people using 256 or 24bits color. Might not be true. But for 16 colors, we also have 'grey', which could replace 'black'. I believe there are more people using 'black' background instead of 'grey' background.
• I'm not expert in this, but checking for TERM.includes('256color') maybe enough?
• I checked http://downloads.sourceforge.net/zsh/zsh-4.3.10-doc.tar.bz2 It supports 256 colours.

Use brightened color for bold is a feature, that can be disabled. I'm not sure if it's the default,

xterm's default behaviour is to render bold black as grey. Indeed, that can be disabled with the +bdc flag (at least) — but anyone setting that should also change the colour values, otherwise they won't be able to see bold black text in any program, not just in z-sy-h.

or all terminals support that. I would rather not assume all terminals have this feature.

That's a red herring. All that z-sy-h assumes is that that a standard foreground colour is readable against the default background colour.

But for 16 colors, we also have 'grey', which could replace 'black'.

What colour would that be? There's { black/red/green/yellow/blue/magenta/cyan/white } × { bright, non-bright }.

I'm not expert in this, but checking for TERM.includes('256color') maybe enough?

I was thinking more of (( ${terminfo[colors]} >= 256 )), but I wasn't sure how sensitive/specific it would be.

I checked http://downloads.sourceforge.net/zsh/zsh-4.3.10-doc.tar.bz2 It supports 256 colours.

Thanks, that's very helpful. The oldest bug report I remember is from a 4.3.9 user in 2016, so 4.3.10 today should be more than old enough.

That's a red herring. All that z-sy-h assumes is that that a standard foreground colour is readable against the default background colour.

on my mac, i use alacritty, iterm2 and terminal. They all have this feature. But they are all disabled by default. Not all programs relies on this feature. They can explicitly specify bright black color echo -e "\033[90mgrey\033[m".

What colour would that be? There's { black/red/green/yellow/blue/magenta/cyan/white } × { bright, non-bright }.

sorry. grey as a name is not supported in zsh. From what I remember you can use 'grey' in Vim. It's actually bright black. But since 256 colors is ok. you can explicitly use fg=8. This does not change anything. Your intention is to use brightened black. Am I correct?

A quote from zsh manual

On recent terminals and on systems with an up-to-date terminal database the number of colours supported may be tested by the command ‘echotc Co’; if this succeeds, it indicates a limit on the number of colours which will be enforced by the
line editor. The number of colours is in any case limited to 256 (i.e. the range 0 to
255).

This built in command is already there for version 4.3.10. So we could take advantage of it directly.

How about this?

• If terminal supports 256 colors. set it to fg=8. This is minimal effort and minimal change.

The code currently uses fg=black,bold. That's what we've been discussing all along. (And to be precise, "bold" and "bright" aren't the same thing, in xterm at least.)

fg=8,bold then. BTW, bright black's translation should be color 8.

Yeah, though we try to avoid forks for Cygwin, and there remains the question of whether the value would be correct (i.e., whether fg=245 would work whenever the number of colours reported is 256).

If it reports 256 but does not really work, it's the problem of terminal developer. But at least I just had a try on cygwin. It's working when i set TERM to xterm-256color

Just noticed this

https://github.com/zsh-users/zsh-autosuggestions/blob/ae315ded4dba10685dbbafbfa2ff3c1aefeb490d/src/config.zsh#L10

fg=8,bold then.

What's the difference between fg=black,bold and fg=8,bold?

If it reports 256 but does not really work, it's the problem of terminal developer.

Well, yes, but the design process doesn't stop at that. Behaviour in failure modes needs to be considered too.

Just noticed this

https://github.com/zsh-users/zsh-autosuggestions/blob/ae315ded4dba10685dbbafbfa2ff3c1aefeb490d/src/config.zsh#L10

So zsh-autosuggestions uses fg=8,bold. Any chance you can grep their issues list for tickets analogous to this one?

What's the difference between fg=black,bold and fg=8,bold?
If it reports 256 but does not really work, it's the problem of terminal developer.

There is not difference on environments with 256 colors support; on 16 colors environment, it seems to fall back to default foreground, which is at least better than being invisible. This fallback seems controlled by zsh, so should be safe?

So zsh-autosuggestions uses fg=8,bold. Any chance you can grep their issues list for tickets analogous to this one?

It has been that way since that file was created.

There is not difference on environments with 256 colors support; on 16 colors environment, it seems to fall back to default foreground, which is at least better than being invisible. This fallback seems controlled by zsh, so should be safe?

Possibly, but there's no point in checking unless we know of at least one terminal where fg=8,bold behaves better than fg=black,bold does.

It has been that way since that file was created.

That's certainly relevant, but doesn't answer the question you were asked.

@danielshahaf Thought I drop in a datapoint in favor of fg=8,bold instead of fg=black,bold. I just tested on both light and dark background using iTerm2 (tokyo_night, {Dark|Light} Background, Solarized {Dark|Light}).