search

zsh-users / zsh-syntax-highlighting

Fish shell like syntax highlighting for Zsh.
github.com/zsh-users/zsh-syntax-highlighting
BSD 3-Clause "New" or "Revised" License
20.11k stars 1.33k forks source link

Comments are invisible #510

Open vinipsmaker opened 6 years ago

vinipsmaker commented 6 years ago

This is a commonly used technique: https://unix.stackexchange.com/questions/33994/zsh-interpret-ignore-commands-beginning-with-as-comments?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa

But with zsh-syntax-highlighting turned on, all characters after # become invisible.

vinipsmaker commented 6 years ago

Nevermind, I found a solution:

ZSH_HIGHLIGHT_STYLES[comment]='none'
danielshahaf commented 6 years ago

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

vinipsmaker commented 6 years ago

Your terminal's colour scheme

Terminology with solarized-light theme.

Comments are highlighted in gray

Thank you.

duhd1993 commented 3 years ago

@danielshahaf Isn't it hard coded as black? https://github.com/zsh-users/zsh-syntax-highlighting/blob/5eb494852ebb99cf5c2c2bffee6b74e6f1bf38d0/highlighters/main/main-highlighter.zsh#L62 Any string starting with a # or $ is completely invisible. I tested in many different terminals with their built in theme. Only iTerm2 shows grayish color. Then I find out that's because iTerm2 sets a minimum contrast. I also tried ssh to a ubuntu server. #string is colored red while $string is also invisible. That seems like unsetopt INTERACTIVE_COMMENTS. But still in ubuntu the default color is also black.

danielshahaf commented 3 years ago

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.

duhd1993 commented 3 years ago

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.

danielshahaf commented 3 years ago

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?

duhd1993 commented 3 years ago
danielshahaf commented 3 years ago

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.

duhd1993 commented 3 years ago

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?

danielshahaf commented 3 years ago

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?

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.)

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.

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).

duhd1993 commented 3 years ago

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

danielshahaf commented 3 years ago

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?

duhd1993 commented 3 years ago

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.

danielshahaf commented 3 years ago

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.

adithyabsk commented 1 year ago

@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}).