Skip to content
This repository has been archived by the owner on Sep 17, 2022. It is now read-only.

Highlighting problems if cursorline is activated #44

Closed
IngoMeyer441 opened this issue Feb 15, 2018 · 7 comments
Closed

Highlighting problems if cursorline is activated #44

IngoMeyer441 opened this issue Feb 15, 2018 · 7 comments

Comments

@IngoMeyer441
Copy link
Contributor

First: Thanks for your project! Chromatica helps a lot for daily work.

If the cursorline setting is activated, the syntax highlighting of chromatica is overriden by the default highlighting:
image
Unfortunately, I am not sure if this is a issue with chromatica, neovim or maybe my colorscheme (vim-one).

@IngoMeyer441
Copy link
Contributor Author

IngoMeyer441 commented Feb 16, 2018

Ok, with a clean install in a Docker container and a minimal vimrc I get the same highlighting problems with the default colorscheme.
If you are a Docker user you can save this Dockerfile:

FROM debian:unstable
LABEL maintainer="Ingo Heimbach <i.heimbach@fz-juelich.de>"

RUN apt-get update && \
    apt-get install --no-install-recommends -y automake \
                                               build-essential \
                                               ca-certificates \
                                               cmake \
                                               curl \
                                               git \
                                               libclang-3.9-dev \
                                               libtool-bin \
                                               pkg-config \
                                               python3-pip \
                                               python3-setuptools \
                                               unzip && \
    rm -rf /var/lib/apt/lists/*

WORKDIR /tmp

RUN git clone https://github.com/neovim/neovim.git && \
    cd neovim && \
    make CMAKE_BUILD_TYPE=Release && \
    make install && \
    cd .. && \
    rm -rf neovim

RUN pip3 install neovim

RUN curl https://raw.githubusercontent.com/Shougo/dein.vim/master/bin/installer.sh > installer.sh && \
    bash installer.sh ~/.vim/dein && \
    rm -f installer.sh

RUN mkdir -p "${HOME}/.config/nvim" && \
    echo 'set runtimepath^=~/.vim runtimepath+=~/.vim/after\n\
let &packpath = &runtimepath\n\
source ~/.vimrc' \
> "${HOME}/.config/nvim/init.vim" && \
    echo "set nocompatible\n\
\n\
set runtimepath+=/root/.vim/dein/repos/github.com/Shougo/dein.vim\n\
if dein#load_state('/root/.vim/dein')\n\
  call dein#begin('/root/.vim/dein')\n\
  call dein#add('Shougo/dein.vim')\n\
  call dein#add('arakashic/chromatica.nvim')\n\
  call dein#end()\n\
  call dein#save_state()\n\
endif\n\
\n\
filetype plugin indent on\n\
syntax enable\n\
set background=dark\n\
set cursorline\n\
\n\
let g:chromatica#libclang_path = '/usr/lib/llvm-3.9/lib'\n\
let g:chromatica#enable_at_startup = 1\n\
let g:chromatica#responsive_mode = 1\n\
let g:chromatica#highlight_feature_level = 0" > /root/.vimrc

RUN echo ":call dein#install()\n" > ./vim_install_plugins && \
    echo '#!/bin/bash\nnvim -s /tmp/vim_install_plugins\nexec "$@"' > /tmp/entrypoint.sh && \
    chmod +x /tmp/entrypoint.sh

WORKDIR /root

RUN echo "#include<stdlib.h>\n#include<stdio.h>\n\
\n\
int main(void) {\n\
    printf(\"Hello World!\");\n\
    return 0;\n\
}" > test.c


ENTRYPOINT ["/tmp/entrypoint.sh"]
CMD ["/bin/bash"]

to Dockerfile, build and run it:

docker build -t chromatica-test:latest .
docker run -it chromatica-test:latest

Neovim opens automatically and installs Chromatica with Dein.vim. When the installation is finished, close Neovim and restart it again with the given test file:

nvim test.c

@arakashic
Copy link
Owner

Thanks for submitting this issue!

This is indeed a problem due to the conflict between the $VIMRUNTIME/syntax/c.vim and the highlight generated by chromatica.

When g:chromatica#highlight_feature_level is set to 0, the full $VIMRUNTIME/syntax/c.vim will be loaded and cause this conflict. In this mode, chromatica only handles the highlight of identifiers and literals. Therefore, it needs the default c.vim to provide highlight for keywords, etc. As a result, the highlights for identifier and literals in c.vim would conflict with chromatica.

A quick workaround is setting g:chromatica#highlight_feature_level to 1. This would allow chromatica to handle all the tokens. In this mode, chromatica will only load a modified version of c.vim (for format specifiers). Conflicts would be rare.

A correct solution would require creating a modified c.vim that eliminates all the possible conflicts. However, it would take some time to chase down all these conflicts. It's on going, but at a very slow pace.

Note, the purpose of setting g:chromatica#highlight_feature_level to 0 is to avoid performance issue on some slow machines. This is because the highlights generated by chromatica is not automatically tracked when the buffer is changed. Frequently updating too many tokens may results in significant slow down, thus restricting the type of tokens that chromatica handles.

@arakashic
Copy link
Owner

Special thanks for providing the docker file! It is super helpful for reproducing the problem!

@IngoMeyer441
Copy link
Contributor Author

Ok, thanks for your detailed response. 😃 I will try to set g:chromatica#highlight_feature_level to 1.

@IngoMeyer441
Copy link
Contributor Author

I have tested some code lines in the Docker container using

let g:chromatica#highlight_feature_level = 1

However, there are still some highlighting problems if cursorline is activated:
image
Include directives are not highlighted correctly if written with angle brackets (independently from the cursorline setting):
image

@arakashic
Copy link
Owner

The highlight conflict on stderr and other "keywords" should have been solved by the latest fix. The highlight problem regarding the header filename and angle brackets is a known problem caused by the parsing of libclang. Will figure that out later.

@IngoMeyer441
Copy link
Contributor Author

Thanks a lot for your work! 👍

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

No branches or pull requests

2 participants