Skip to content
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

Strange pink highlight in some words - is this by design? #248

Closed
gregth opened this issue May 7, 2021 · 9 comments
Closed

Strange pink highlight in some words - is this by design? #248

gregth opened this issue May 7, 2021 · 9 comments

Comments

@gregth
Copy link

gregth commented May 7, 2021

What happened

Some words in vim appear highlighted with pink color. For example, when using Tagbar plugin for go language outline, or at the intro screen of VIM.

What I expected to happen

This highlight is irritating, is this a bug or just a design decision?

Screenshot

At right bottom is the Tagbar with the pink highlights:
image

Another case, at the vim intro screen:
image

The following screenshot is what I get when I run vim without loading plugins, which means with Dracula for vim disabled (still I have Dracula theme for my gnome-terminal enabled):

image

Machine Info

Linux Dellis 4.15.0-142-generic #146-Ubuntu SMP Tue Apr 13 01:11:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

  • Vim type (vim/gvim/neovim): vim
  • Vim version: VIM - Vi IMproved 8.0
  • OS: Ubuntu 18.04
  • Terminal/Terminal Emulator/VTE: gnome-terminal
  • TERM environment variable: screen
@benknoble
Copy link
Member

Hmm, looks like the SpecialKey might be off--do you change that in your config? Could another plugin? Try :verbose highlight SpecialKey

@gregth
Copy link
Author

gregth commented May 7, 2021

@benknoble you are right! There was a line in my .vimrc that altered the SpecialKey.
I removed the line and now the colors are grey-ish, which makes them quite indistinguishable, is that the expected behavior?

Now I get:

:verbose highlight SpecialKey
SpecialKey     xxx term=bold ctermfg=4 guifg=Blue
                   links to DraculaSubtle
        Last set from ~/.vim/bundle/dracula/colors/dracula.vim

image

Thank you for your help!

@benknoble
Copy link
Member

benknoble commented May 7, 2021

Unfortunately for the moment, this is "intended"… due to a quirk (#192 #210 ) that neovim & vim use (slightly) different highlight groups for trailing whitespace, which we would like to be more subtle. Vim uses SpecialKey, which also get's used for stuff like <CR>/etc. (the output of :map is also not-fun if you have special keys). NeoVim, IIUC, uses a different group, so we can style the trailing whitespace separately from the special keys. I think @dsifford uses NeoVim and can give more context on this.

If you really don't like it, one simple fix is

augroup dracula_custom
  autocmd!
  autocmd ColorScheme dracula highlight! link SpecialKey DraculaPink
augroup END

(or whatever your preferred color is)

@dsifford
Copy link
Member

dsifford commented May 7, 2021

@benknoble Neovim uses SpecialKey exclusively for non-printable characters and Whitespace for any other whitespace character highlighting (i.e. the listchars)

@benknoble
Copy link
Member

benknoble commented May 7, 2021

@dsifford I would like to revisit the issues I linked above at some point (I think #210 is the most relevant). To me it's worth making vim's listchars stuff a little more visible if it makes other UI elements that use the same group easier to deal with. (And, note, vim doesn't use just SpecialKey but NonText for certain elements.)

The other option would be to try to get vim to use a different/new group for list chars (Whitespace?) with PRs/discussion on the source.

@dsifford
Copy link
Member

dsifford commented May 7, 2021

Definitely open to making those changes. Happy to put our heads together if you want to get a PR started.

benknoble added a commit that referenced this issue May 20, 2021
Related: #192, #210, #248

Also #247 is about `NonText`, which needs investigating.

Issues: `:digraphs`, special keys in `:map` output, and certain parts of
`'listchars'` are "subtle" and hard to read (esp. w/ `cursorline` over
them). Also, vim uses `SpecialKey` for them (instead of `Whitespace` for
`'listchars'` and `SpecialKey` elsewhere, like NeoVim).

Fix: make `SpecialKey` more like special keys (the highlight in vimscript
for, e.g., `map <Space> :echo "hello"<CR>`). This has the side effect of
making digraphs more visible. It also makes certain `'listchars'` pink,
which may be annoying. But there is no way currently to separate the two
in vim.

Rationale: It matches with the special keys in maps. The fact that vim
uses it elsewhere may simply be "wrong" and need changed.

If you don't like it: well, as usual, you can use an autocommand to use
whatever colors you want (`:help dracula-customization`).
@benknoble
Copy link
Member

Hi @gregth, I'm looking for feedback on #252, which should help ameliorate that "hard to read grey" in some places. Any thoughts, positive or negative?

dsifford pushed a commit that referenced this issue Jun 4, 2021
Related: #192, #210, #248

Also #247 is about `NonText`, which needs investigating.

Issues: `:digraphs`, special keys in `:map` output, and certain parts of
`'listchars'` are "subtle" and hard to read (esp. w/ `cursorline` over
them). Also, vim uses `SpecialKey` for them (instead of `Whitespace` for
`'listchars'` and `SpecialKey` elsewhere, like NeoVim).

Fix: make `SpecialKey` more like special keys (the highlight in vimscript
for, e.g., `map <Space> :echo "hello"<CR>`). This has the side effect of
making digraphs more visible. It also makes certain `'listchars'` pink,
which may be annoying. But there is no way currently to separate the two
in vim.

Rationale: It matches with the special keys in maps. The fact that vim
uses it elsewhere may simply be "wrong" and need changed.

If you don't like it: well, as usual, you can use an autocommand to use
whatever colors you want (`:help dracula-customization`).
@benknoble
Copy link
Member

I think this is resolved, so I'll close it for now. Let us know if it is not resolved.

@gregth
Copy link
Author

gregth commented Jun 24, 2021

@benknoble I apologize, I missed the notification for your mention.
I just pull the latest master commits, and the fix seems good!

Thank you for working on this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants