leafOfTree/vim-vue-plugin

Syntax highlighting issue

Amndeep7 opened this issue · 13 comments

Seems like if you scroll too fast or do too big a movement command, the syntax highlighting doesn't occur properly - nearly all text stays unhighlighted grey though occasional words are colored incorrectly if the movement is too big/fast, but if you make the text go back off screen and then scroll down slowly it reappears correctly colored.

Stack: vim-vue-plugin > vim-plug > neovim (at head via brew) > alacritty > macbook pro 2018 (mojave)

Thank you for the feedback. It seems to be a redraw issue and I also have it sometimes when moving too fast, but I can't reproduce it to find out a reason. Could you please try

  • :set nolazyredraw
  • or the same content with a different filetype like html

to see if any of them solves the problem? Or it only happens with this plugin?

Hello, thanks for acknowledging the issue.

  1. nolazyredraw is the default value.
  2. Changing the file type of a Vue file to html makes it so that it's not grey but the highlighting remains incorrect.
  3. posva/vim-vue does not have these issues at all nor does any other syntax highlighting plugin.

Something interesting that I saw when I changed the file type to html and then back to vue is that the syntax highlighting issue actually went away even with rapid movement. The same holds true when you manually set the file type to vue when you first open the file (i.e. when it already thinks that the file type is vue).

Hi, sorry for the late response.

I installed neovim(at head via brew too) and alacritty on MacOS Cataline(pro2017), tried some .vue files, but the syntax seems to render well.

Could you please show me a .vue file and a movement command that causes the error, so I can try to reproduce the issue?

$ nvim --version
NVIM v0.5.0-nightly
Build type: Release

alacritty: brew cask install alacritty showed its version is v0.4.1

Sorry for my own late response:

macOS Catalina 10.15.3, MacBook Pro 2019

Alacritty version:

$ brew cask info alacritty
alacritty: 0.4.1
https://github.com/jwilm/alacritty/
/usr/local/Caskroom/alacritty/0.4.1 (123B)
From: https://github.com/Homebrew/homebrew-cask/blob/master/Casks/alacritty.rb
==> Name
Alacritty
==> Artifacts
Alacritty.app (App)

Nvim version:

$ nvim --version
NVIM v0.5.0-nightly-275-gdb436d5
Build type: Release
LuaJIT 2.0.5
Compilation: /usr/local/Homebrew/Library/Homebrew/shims/mac/super/clang -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNDEBUG -DMIN_LOG_LEVEL=3 -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -I/tmp/neovim-20191112-61210-1wygvr6/build/config -I/tmp/neovim-20191112-61210-1wygvr6/src -I/usr/local/include -I/tmp/neovim-20191112-61210-1wygvr6/deps-build/include -I/usr/local/opt/gettext/include -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include -I/tmp/neovim-20191112-61210-1wygvr6/build/src/nvim/auto -I/tmp/neovim-20191112-61210-1wygvr6/build/include
Compiled by me@macFeatures: +acl +iconv +tui
See ":help feature-compile"   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/usr/local/Cellar/neovim/HEAD-db436d5/share/nvim"Run :checkhealth for more info

my init.vim

sample file that I found by doing a search for vue files on github

screen capture of me scrolling in that file

In the screen capture, I used gg and G to do the big jumps up and down the file. I used the mouse to scroll when you saw scrolling.

Hi, thank you for all the useful information. It turns out that the syntax issue in nvim was caused by setlocal matchpairs+=<:> which is used to enable % in the template tags. nvim handles % so well that it doesn't need it.

ad44fd0 should fix it now.

Pulled down the latest but still experiencing the same issue when I rapidly scrolled up and down - at some point the syntax highlighting would stop working properly on certain sections or even the entire document. Also, still verified that if I set the syntax type to vue manually, then I couldn't get the syntax highlighting to break.

Hmm, I seem to have found another trigger to cause the syntax highlighting to stop working. And this one also causes the set syntax=vue trick to fail.

The trigger for me was to have a variable in data that I'm manually setting to be a very large (character wise) array of objects.

e.x.

data() {
  return {
    ...,
    testData: [{"id": "test1"}, {"id": "test2", "arr": ["val"]}, 3000 characters later],
  };
},

That array was all on one line, just to clarify. All 3000+ characters.

I'm not sure if this is the same issue to yours. I opened a long .vue file, jumped to bottom by G, then moved up half-page once upon a time by <c-u>. The syntax highlighting in the script or template was broken and became grey.
I think it was caused by vim :h syn-sync. The set syntax=vue you mentioned did the trick by loading syn-sync settings from html. I added syntax sync match... to fix it. It seems to work and keep fast now. 7df45df
If it doesn't work for you, you can try to add syntax sync fromstart for .vue files. The documentation says this makes syntax highlighting accurate, but can be slow for long files.

For 3000+ characters on one line, Vim has a maximum column for syntax items. :h 'synmaxcol'. You can set it to zero to remove the limit.

Summary:

  • Update vim-vue-plugin to see if it works
  • If not, try syntax sync fromstart

This is like 99% of the way there. I noticed that sometimes certain keywords were not highlighted correctly in some sections (not the entire document) after doing a lot of jumps, but coming up with something you can reproduce is going to be hard. I didn't try syntax sync fromstart cause I just restarted nvim when I noticed it and the issue hasn't come back yet. Will keep you informed.

Ok, had that incorrect syntax highlighting again, but using syntax sync fromstart fixed it. I think this issue is good to be closed.

Well, not perfect, but it works at least.