conflict with vim-easymotion

[Kztpia]

Describe the bug
highlight disappear after running a vim-easymotion action

To Reproduce

1. with text highlighted
2. run easymotion command, in my case "w"
   whtih "nmap w (easymotion-bd-w) "
   " Plug 'easymotion/vim-easymotion' " in my .vimrc
3. after easymotion done, highlight in current screen disappear
4. :LspCxxHighLight will make highlight reappear

it seems highlight from LspCxxHighLight only active when file first open or modified.
maybe some additional check or hook required after plugin like vim-easymotion
highlight current screen in a different way, to make highlight from lsp-cxx-highlight
reappear

[solotim]

Get the same issue. What's your solution then?
Is there an alternative to this plugin?

[jackguo380]

Hi @Kztpia and @solotim

I hate to make excuses but I suspect easymotion is at fault here, it's likely one of the motions you are using is globally clearing all highlighting of some type. I don't have a lot of time at the moment but when I do I'll try to file a bug with them after investigating.

This is quite prone to happen if you are using the legacy "match" coloring backend. Match uses the same API as a lot of plugins to provide temporary highlighting (matchaddpos) and can be easily stomped upon by those plugins as there's a way to globally clear all matches (clearmatches). vim-lsp-cxx-highlight tries very hard to not affect other plugins when using this API by only clearing matches added by the plugin but the same cannot always be said the other way around.

The main workaround is to use the textprop backend, match was always a hack born out of not having a better option in old versions of vim, textprop solves the issues with match as it's made specifically for this purpose. This backend should be enabled automatically on vim 8.2+, but given that this bug report exists you're probably on a older version. You can force enable it via:

let g:lsp_cxx_hl_use_text_props = 1

Note: Textprop's API has been around since about vim 8 but was very buggy and missing features, I would say halfway from 8.1 to 8.2 was when it was finally stable enough to use in this plugin. If you experience weird problems, try compiling the latest vim from git first.

Neovim has a equivalent API that is also version gated (somewhat arbitrarily), but it should be enabled automatically on pretty much most versions of neovim out in the wild.

Please let me know if this fixes it.

[solotim]

Hi Jack,
Thanks for the WA. It seems to work.
But I eventually have to stop using this lovely plugin because I noticed some latency during file editing, or big file loading. The vim-lsp-cxx-highlight seems to (or have to) run in foreground to render the colors, I guess, and it caused vim being frozen.

I still think this plugin is cool. But I don't want to sacrifice my typing experiences for it.

Thanks
solotim

[jackguo380]

@solotim

I'm quite surprised to hear that. I had developed this plugin for work and continue to use there daily where there are quite a few very large C++ files (5-10K+ lines). I haven't had any major issues with this overall. Could you provide some logs so I could see if there's something I could do to fix it for you?

On the technical side, yes, the plugin does do computation in the foreground because vim is single threaded and this plugin is implemented in vimscript. But this should only happen after saving a file and for most reasonably sized C++ files it usually takes only a few 100 ms to process.

I had thought of farming out parts of the work to a separate process to avoid blocking as long. But never ended up doing it as I estimated that the time saved blocking wouldn't be enough to justify it as half the work is calling the highlight APIs and that cannot be separated.

[jackguo380]

Actually I had just read another bug report for clangd (#63) which sounds a lot like your problem @solotim.

I implemented a experimental feature for fixing it, could you give it a try? (see my comment on that issue)

[solotim]

@jackguo380
Thanks for the info.
The "large" file I mentioned are really large, over 40k . I can close semantic highlight for that, so not a big deal. The more important issue is the typing experience.

I tried your new "feature-mode-delay" branch and the recommended two settings. I can sense the improvement during typing but it's unfortunately not enough. Once stop typing for 1000ms the plugin begin to work in foreground and vim stuck again. Usually at the moment I'm in VIM normal mode and will do lots of things, can't wait.

My gut feeling is that the "delay" approach is not a thorough solution for it. I don't know how to write vim plugin, so just my speculation.

[jackguo380]

@solotim

Thanks for trying it out. Yea it's largely experimental which is why it's on it's own branch, still trying to figure out how to make it better overall.

My gut feeling is that the "delay" approach is not a thorough solution for it. I don't know how to write vim plugin, so just my speculation.

You aren't wrong, it was something I thought of at the moment and didn't extensively test, given that you are still having issues maybe this isn't the solution. One other idea I had was maybe delaying all highlighting updates until a save like how it works on ccls.

Unfortunately, a lot of the design issues of this plugin is due to limitations in vim itself such as the slow language and single-threadedness. Using vim as an end user overall is pretty nice, but the programming APIs are generally quite poor.

I can close semantic highlight for that, so not a big deal.

Not sure if you had already found this, but if you're okay with disabling highlighting on the large file then I had implemented this previously for another issue: #5 (comment)

:LspCxxHighlightDisable disables highlighting for a particular buffer. You could hook it up to an autocmd even.

:LspCxxHighlight re-enables it.