regression: Re-include hi clear etc in apply breaks highlight for startup screen

[brunnre8]

7556467 breaks the highlights for the initial screen when nvim is started (v0.8.0-dev+266-g976f32aa7a, but same thing happens on the v0.7* release)

I've bisected the issue to the above mentioned commit.

The issue manifests itself when one just starts nvim, without doing anything

lush.nvim v1.0.0:

lush.nvim main:

Issuing some nonsensical highlight command then resets the highlights to the proper colors (though that does get rid of the welcome screen so it's harder to tell).

So something seems to be off or missing a redraw request to nvim?
Not sure if this is a lush bug or neovim, in case I can help you in any way please say how.

[rktjmp]

Thanks for the bisect!!!

I will try and get a clean reproduction locally. What terminal and system are you on, probably not relevant but good to know.

I did notice something similar when doing the lua-hl update but at that time it was an actual bug (from memory, it was related to the code posted, not calling hl-clear, but in the realtime lushify side), but when I fixed that I never saw it again.

My suspicion was that it was something in nvim itself and the lua highlight API, where:

• you already have a highlight drawn
• you update that highlight definition via the lua api, with some unspecified internal nvim conditions
• the highlight may not be updated on-screen (?)

It's possible that the vim.cmd & nvim_set_hl have some kind of collision.

You could experiment with sticking a :redraw command in there, before and after we pass the hl-defs to the API and see if that has any effect. Ideally we would not have to call that each time as I think it can have a noticeable performance impact.

You could also check set lazyredraw?, which may have an effect. Mine is nolazyredraw for reference.

I also wonder if applying the commands one at a time, and ensuring the g:colors_name has an actual value (are we running before it has one? it should have a value...) may have an effect.

[rktjmp]

Can you confirm whether you are setting the highlight group SpecialKey?

You can see the value and where it is set with :verbose hi SpecialKey

:verbose hi SpecialKey
SpecialKey     xxx guifg=red
        Last set from ~/my-theme/theme.vim line 20

e: actually I see the status line is also mis-coloured.

Also how are you applying your scheme, with colors/x.vim or colors/x.lua?

[brunnre8]

Yeah, SpecialKey is set, funnily enough it also shows all the proper highlights as set by lush (:hi shows what I'd expect based on my color scheme)

set lazyredraw? is the default, meaning nolazyredraw

What makes the highlights update properly for me is opening up the help with :h $whatever that then does the necessary redraw for the colors.

:redraw doesn't do anything to the colors when I call it manually

Also how are you applying your scheme, with colors/x.vim or colors/x.lua?

How do I check?
All I'm doing is cmd([[colorscheme gruvbox]]) from my init.lua

the lush plugin is based on some older version of the skeleton... repo is here if that helps: https://github.com/brunnre8/gruvbox.nvim

I'm sadly not very familiar with the highlight functionality of nvim myself (hence me using lush 😉 )

[brunnre8]

I will try and get a clean reproduction locally. What terminal and system are you on, probably not relevant but good to know.

Missed that part, sorry:

• terminal: alacritty 0.10.1
• vim: v0.8.0-dev+522-g514e76e4b2 (but the issue reproduces on the non nightly v0.7 release)
• OS:: Arch linux, kernel:5.18.8-arch1-1

[nanzhong]

A temporary workaround that I've been using is to just call lush.apply directly and not setting force_clean (which seems to be set by default if using the detect_easy approach (https://github.com/rktjmp/lush.nvim/blob/main/lua/lush.lua#L77).

[rktjmp]

I have gotten a reproduction in a container. I couldn't reproduce it with my own config and I cant say what the difference is. Even disabling all my plugins and settings wont reproduce it locally. I even have basically the identical setup os/term wise as you.

Including the hi clear is standard/recommended when loading colorschemes so I don't really want to remove it - at least it was recommended in viml themes. nvim_set_hl will replace highlights as opposed to update them as the hi ... command does so there's less potential for "mixed themes" with the lua interface beyond old highlight groups hanging around if the new theme doesn't re-define them. Perhaps it would be safe to remove...

I stuck an echo 'xxx' command in with the others while also printing out the group names as they're sent out in case the commands were some how running out of sync and it all seemed in order (whether they get buffered internally is unclear).

Tried wrapping the calls in one, or separate vim.schedules, just in case, which had no effect beyond hiding the intro screen.

Not really sure how to proceed or what else to test...

[nanzhong]

Out of curiosity, what plugin manager do you use? I wonder if there could be any relation between the way a plugin manager loads things that could be causing this behaviour?

[rktjmp]

Fixed in 3df0790.

A clean install of neovim 0.7.2, lush and brunnre8/gruvbox.nvim, inside a arch container does reproduce the issue. Zero idea what it is about my "actual" install that wont reproduce it. Must be some file somewhere.

Anyway, all that aside, it's at least more reproducible than non-reproducible.

Applying any kind of highlight via the old command fixes it, so we just include one after we finish calling nvim_set_hl. I think this is probably a upstream bug, where nvim_set_hl data isn't getting pushed "all the way" in some cases.

I imagine the effect is quite wide spread but most people open a file directly, have a start up screen or some other plugin, one of these things is bound to call :highlight ... and then all the highlights are applied correctly.

[brunnre8]

Thanks a bunch!