LanguageClient-neovim: syntax highlighting (errors and warnings) doesn't disappear after fixing the errors

  • Did you upgrade to latest plugin version? Yes
  • Did you upgrade to/compile latest binary? Run shell command bin/languageclient --version to get its version number. Yes. I do run install.sh everytime I upgrade.
  • (Neovim users only) Did you check output of :checkhealth LanguageClient? N/A
  • Did you check troubleshooting? Yes

Describe the bug

When resolving a syntax error in a file, the error red highlighting is still applied on the line where the bug was and it doesn’t go away. I have to restart Vim in order for the highlighting to be reset.

Here is a minimal example:

https://github.com/sim590/language-client-highlight-bug

Environment

  • neovim/vim version (nvim --version or vim --version):

    VIM - Vi IMproved 8.2 (2019 Dec 12, compilé Feb 09 2021 23:51:55)
    
  • This plugin version (git rev-parse --short HEAD): a42594c

  • This plugin’s binary version (bin/languageclient --version): languageclient 0.1.161

  • Minimal vimrc content (A minimal vimrc is the smallest vimrc that could reproduce the issue. Refer to an example here): It is part of the minimal example repository.

  • Language server link and version: https://github.com/haskell/haskell-language-server

To Reproduce

Steps to reproduce the behavior:

  1. Fetch the minimal example and enter the repository:

    $ git clone https://github.com/sim590/language-client-highlight-bug
    $ cd language-client-highlight-bug
    
  2. Open the Main.hs file.

  3. Execute the vim normal script: 7Gf=wC undefined^[ where ^[ is the escape key.

Current behavior

The word undefined is highlighted in red even though it is correct syntax.

LanguageClient highlights this region when undefined is being written, so when it sees for instance undef, it correctly highlights the word in red, but as soon as the syntax is correct, i.e. that you write the final d, you can see that the error symbol in the left column is gone, but a subword like undefine is highlighted in red (but not the letter d).

Expected behavior

The highlighting should disappear when an error/warning is fixed.

Screenshots

vim

Additional context

It seems like fixing the warning just above (the line with my_func) does go around the issue. However, you understand that it is not always possible to do so. Sometimes, it doesn’t help either and you have to restart Vim in order to retrieve a usable state.

About this issue

Commits related to this issue

Most upvoted comments

I’m having the same issue with multiple different language servers. I’m still very unsure what it’s caused by (could also be a VIM bug).

You can remove these artifacts by running :call clearmatches() to continue working in the same buffer.

Hi there, same bug here but with dotnet + ionide-vim, fsharp project.

No need to restart vim, though. Just splitting the buffer refreshes the highlight…

Hm, might need to get more of the logic inside the lock then. I’ll ping you when I have a branch with that so you can test it out.

So I played with it a bit and I can say that the minimal example is fixed, but there are still issues. I can’t say how to reproduce them just yet. But here’s a screen capture:

still

Actually, I guess locking specifically that bit out should be fine, so I opened #1211. If you have Rust installed and want to give that a try and see whether you can still reproduce that would be great. I’m no longer able to do reproduce the issue with that branch now, but extra eyes are always welcome.

Also, if everything works out fine I’ll be merging this to the dev branch, so hopefully you’ll have a working version you can use sooinsh, a proper release cut will take a few more days but I’ve been meaning to cut a release for quite a while now so I’ll probably do once we have tested this thoroughly.

I’m gonna borrow your repo there and open an issue on the haskell-language-server repo to see if this is something that needs their attention or if it’s intentional.

Alright, I was able to reproduce following your steps now, so no need for the log output. It seems like it only happens in vim, not happening in neovim, so definitely something weird our side. I’ll see if I can find the culprit.