Cor do primeiro plano da SpecialKey com conjunto de linhas do cursor

Em este Q & A , observa-se que há um grupo destaque para CursorLineNr, que se aplica ao número da linha para a linha de cursor quando set cursorlineestá ligado.

Percebo que o uso da linha do cursor também altera a cor de outro grupo de destaque SpecialKey, que se aplica se você tiver, por exemplo:

 set list listchars=tab:\|_,trail:-

O problema disso é que eu uso um fundo escuro (e, portanto, uma linha de cursor escura). Minha SpecialKeyconfiguração normal também é muito escura, de modo que os listcharsímbolos são apenas um pouco visíveis. Mas usar cursorline eles é branco , o que torna o trailcaracter indistinguível de ter realmente atingido -. O caractere de trilha é usado toda vez que você digita um espaço no final de uma linha, portanto, isso é mais do que um problema menor; normalmente, digitar uma linha do começo ao fim envolve vários espaços que devem ser facilmente distinguidos de um erro de digitação de traço durante o trabalho (ou vice-versa, um erro de digitação de espaço quando você pretendia um traço).

Como nenhum dos outros grupos de destaque parece ser afetado, algo como CursorLineNrprovavelmente está sendo aplicado, mas olhando a hilista, não vejo nada apropriado.

Alguém sabe o que é isso? Melhor ainda, alguém sabe como modificar qualquer grupo de destaque para a linha do cursor?

Eu tenho lutado com esse comportamento há muito tempo.

Basicamente, a cor de primeiro plano de SpecialKeyna linha atual é alterada para a cor de primeiro plano de Normalse:

• a cursorlineopção está ativada,
• o CursorLinegrupo de destaque tem uma cor de fundo definida.

Eu nunca fui capaz de corrigir esse comportamento, não importa o que eu tentei. O problema está em algum lugar no código fonte do Vim.

O que funcionou para mim foram as seguintes linhas no meu .vimrc(com base na resposta de Igor Mikushkin ).

autocmd BufNewFile,BufRead * call matchadd('SpecialKey', '\s\+')
autocmd BufNewFile,BufRead * call matchadd('NonText', '\n\+')

VimEntersó funciona para o primeiro arquivo que você abre, não para arquivos / guias que você abre posteriormente. BufNewFile,BufReadfuncionou até agora para todos os buffers que abri.

A primeira linha abrange caracteres em branco. O Vim os destaca no SpecialKeygrupo, então aplicamos esses estilos a eles.

A segunda linha abrange novas linhas. O Vim os destaca no NonTextgrupo, então aplicamos esses estilos a eles. Você realmente só precisa da segunda linha se seus NonTextcaracteres estiverem destacados de maneira diferente dos SpecialKeycaracteres.

As linhas a seguir em .vimrc corrigiram o problema para mim.

au VimEnter * call matchadd('SpecialKey', '^\s\+', -1)
au VimEnter * call matchadd('SpecialKey', '\s\+$', -1)

Ele substitui o aplicativo de outros estilos por tabulações e espaços finais dentro de uma linha do cursor.

Existe ainda outra "solução", na verdade uma espécie de argumento para esse problema.

Eu tenho grupos de sintaxe personalizados para "listchars".

Como isso:

hi WhiteSpaceChar ctermfg=251 guifg=#999999
call matchadd("WhiteSpaceChar", "[ \t]")

Você poderia fazer algo assim (embora eu não o testasse):

hi TrailChar ctermfg=251 guifg=#999999
" the \v in the regex is Vim's flag to use Perl-like regex syntax
call matchadd("TrailChar", "\v +$")

Mas há pelo menos dois problemas com essa abordagem:

1. quando você divide uma janela ou cria uma nova guia etc., o destaque fica quebrado na janela atual, assim:

Para corrigir isso, tenho funções especiais como:

fun! ResetHiglightJS()
  set syntax=javascript
  "these are for the IndentLine plugin
  "IndentLinesDisable
  "IndentLinesEnable
endfun

para cada grupo de sintaxe, que eu uso com frequência, para corrigir o realce manualmente. Você pode fazer isso de outra maneira, como comandos automáticos ou configurando manualmente o valor da opção de sintaxe. Para que a redefinição da sintaxe funcione, é necessário também ter o seguinte:

call matchadd("WhiteSpaceChar", "[ \t]")

em cada arquivo de sintaxe correspondente, como ~/.vim/after/syntax/javascript.vim

2. Essa abordagem não funciona normalmente com pelo menos um plug-in - o IndentLine, então fui forçado a manter uma versão antiga configurando manualmente let g:indentLine_newVersion = 0, onde o plug-in funcionava normalmente.

Mas, de outra maneira, essa abordagem funciona normalmente sem o plugin IndentLine:

E aceitável com isso: