search

rktjmp / lush.nvim

Create Neovim themes with real-time feedback, export anywhere.
MIT License
1.44k stars 47 forks source link

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

Closed brunnre8 closed 2 years ago

brunnre8 commented 2 years ago

755646717d4c7e538db8e231e5c7293114a9cb7c 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: v1 0 0

lush.nvim main: 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).

main_after_hi

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 commented 2 years ago

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:

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 commented 2 years ago

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 commented 2 years ago

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) specialKey

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. help

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

redraw

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 :wink: )

brunnre8 commented 2 years ago

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:

nanzhong commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

I removed all plugins besides lush and the op's theme, so no plugin manager, and the only thing in my init.lua is termguicolors and then setting the colorscheme.

I did just notice that I can reproduce it with a dev build, where I set the runtime dir.

Eg:

VIMRUNTIME=runtime build/bin/nvim

I wonder if my local install (via pacman) effects something (ships with different runtime files?), or possibly its a debug vs release build thing? Or simply for whatever reason 0.7.2 wont repro on my machine but 0.8.0 will. Running build/bin/nvim without setting the runtime does not reproduce, so it's not a version or debug vs release thing.

I will have a poke around at that.

The --startuptime log of my non-reproducing setup includes some plugin files from system wide tools (fzf and black, which look reasonable at a peek) as well as arch.vim which just sets the rtp, but possibly there's something in there.

times in msec
 clock   self+sourced   self:  sourced script
 clock   elapsed:              other lines

000.006  000.006: --- NVIM STARTING ---
000.263  000.257: locale set
000.576  000.313: inits 1
000.622  000.046: window checked
000.625  000.002: parsing arguments
003.106  002.481: init lua interpreter
003.205  000.099: expanding arguments
003.250  000.044: inits 2
003.735  000.485: init highlight
003.736  000.001: waiting for UI
004.494  000.758: done waiting for UI
004.532  000.038: init screen for UI
004.552  000.020: init default mappings
004.578  000.027: init default autocommands
005.403  000.069  000.069: sourcing /usr/local/share/nvim/runtime/ftplugin.vim
005.513  000.044  000.044: sourcing /usr/local/share/nvim/runtime/indent.vim
005.590  000.013  000.013: sourcing /usr/share/nvim/archlinux.vim
005.593  000.040  000.027: sourcing /etc/xdg/nvim/sysinit.vim
011.093  004.771  004.771: sourcing /home/soup/.local/share/nvim/site/pack/manual/start/gruvbox.nvim/colors/gruvbox.vim
011.106  005.478  000.708: sourcing /home/soup/.config/nvim/init.lua
011.114  000.905: sourcing vimrc file(s)
011.225  000.057  000.057: sourcing /usr/local/share/nvim/runtime/filetype.lua
018.913  000.020  000.020: sourcing /usr/share/vim/vimfiles/ftdetect/PKGBUILD.vim
018.964  000.031  000.031: sourcing /usr/share/vim/vimfiles/ftdetect/meson.vim
019.097  007.848  007.797: sourcing /usr/local/share/nvim/runtime/filetype.vim
019.294  000.086  000.086: sourcing /usr/local/share/nvim/runtime/syntax/synload.vim
019.420  000.267  000.181: sourcing /usr/local/share/nvim/runtime/syntax/syntax.vim
020.106  000.042  000.042: sourcing /usr/local/share/nvim/runtime/plugin/diagnostic.vim
020.373  000.247  000.247: sourcing /usr/local/share/nvim/runtime/plugin/gzip.vim
020.412  000.016  000.016: sourcing /usr/local/share/nvim/runtime/plugin/health.vim
020.510  000.079  000.079: sourcing /usr/local/share/nvim/runtime/plugin/man.vim
021.121  000.232  000.232: sourcing /usr/local/share/nvim/runtime/pack/dist/opt/matchit/plugin/matchit.vim
021.260  000.729  000.498: sourcing /usr/local/share/nvim/runtime/plugin/matchit.vim
021.447  000.165  000.165: sourcing /usr/local/share/nvim/runtime/plugin/matchparen.vim
021.917  000.448  000.448: sourcing /usr/local/share/nvim/runtime/plugin/netrwPlugin.vim
022.113  000.010  000.010: sourcing /home/soup/.local/share/nvim/rplugin.vim
022.122  000.166  000.156: sourcing /usr/local/share/nvim/runtime/plugin/rplugin.vim
022.254  000.108  000.108: sourcing /usr/local/share/nvim/runtime/plugin/shada.vim
022.313  000.029  000.029: sourcing /usr/local/share/nvim/runtime/plugin/spellfile.vim
022.494  000.156  000.156: sourcing /usr/local/share/nvim/runtime/plugin/tarPlugin.vim
022.623  000.097  000.097: sourcing /usr/local/share/nvim/runtime/plugin/tohtml.vim
022.669  000.021  000.021: sourcing /usr/local/share/nvim/runtime/plugin/tutor.vim
022.900  000.208  000.208: sourcing /usr/local/share/nvim/runtime/plugin/zipPlugin.vim
023.854  000.075  000.075: sourcing /usr/local/share/nvim/runtime/autoload/provider/pythonx.vim
079.111  000.218  000.218: sourcing /usr/local/share/nvim/runtime/autoload/remote/host.vim
079.228  055.514  055.221: sourcing /usr/local/share/nvim/runtime/autoload/provider/python3.vim
079.255  056.228  000.714: sourcing /usr/share/vim/vimfiles/plugin/black.vim
080.108  000.819  000.819: sourcing /usr/share/vim/vimfiles/plugin/fzf.vim
080.426  001.580: loading rtp plugins
080.655  000.041  000.041: sourcing /home/soup/.local/share/nvim/site/pack/colorschemes/start/lush.nvim/plugin/lush.vim
080.907  000.440: loading packages
080.925  000.018: loading after plugins
080.939  000.014: inits 3
097.909  016.970: reading ShaDa
098.030  000.121: opening buffers
098.078  000.048: BufEnter autocommands
098.081  000.003: editing files in windows
098.179  000.098: VimEnter autocommands
098.183  000.004: UIEnter autocommands
098.185  000.002: before starting main loop
098.598  000.414: first screen update
098.600  000.002: --- NVIM STARTED ---
rktjmp commented 2 years ago

My pacman install sources a plugin/diagnostic.vim which is not included in the main repo. (Adjusted the VIMRUNTIME log paths so they diff cleanly)

--- startuptime-build-0.7.2-with-runtime-filtered.log   2022-07-13 21:02:22.924955486 +1000
+++ startuptime-pacman-0.7.2-filtered.log       2022-07-13 21:02:24.748300229 +1000
@@ -21,6 +21,8 @@
 sourcing /usr/local/share/nvim/runtime/plugin/man.vim
 sourcing /usr/local/share/nvim/runtime/plugin/health.vim
 sourcing /usr/local/share/nvim/runtime/plugin/gzip.vim
+sourcing /usr/local/share/nvim/runtime/plugin/diagnostic.vim
+sourcing /usr/local/share/nvim/runtime/pack/dist/opt/matchit/plugin/matchit.vim
 sourcing /usr/local/share/nvim/runtime/indent.vim
 sourcing /usr/local/share/nvim/runtime/ftplugin.vim
 sourcing /usr/local/share/nvim/runtime/filetype.vim
@@ -28,7 +30,6 @@
 sourcing /usr/local/share/nvim/runtime/autoload/remote/host.vim
 sourcing /usr/local/share/nvim/runtime/autoload/provider/pythonx.vim
 sourcing /usr/local/share/nvim/runtime/autoload/provider/python3.vim
-sourcing /home/soup/projects/neovim/runtime/pack/dist/opt/matchit/plugin/matchit.vim
 sourcing /home/soup/.local/share/nvim/site/pack/manual/start/gruvbox.nvim/colors/gruvbox.vim
 sourcing /home/soup/.local/share/nvim/site/pack/colorschemes/start/lush.nvim/plugin/lush.vim
 sourcing /home/soup/.local/share/nvim/rplugin.vim
@@ -58,3 +59,4 @@
 UIEnter autocommands
 BufEnter autocommands
 --- NVIM STARTING ---
+--- NVIM STARTED ---

diagnostic.vim

" :help vim.diagnostic

hi default DiagnosticError ctermfg=1 guifg=Red
hi default DiagnosticWarn ctermfg=3 guifg=Orange
hi default DiagnosticInfo ctermfg=4 guifg=LightBlue
hi default DiagnosticHint ctermfg=7 guifg=LightGrey

hi default DiagnosticUnderlineError cterm=underline gui=underline guisp=Red
hi default DiagnosticUnderlineWarn cterm=underline gui=underline guisp=Orange
hi default DiagnosticUnderlineInfo cterm=underline gui=underline guisp=LightBlue
hi default DiagnosticUnderlineHint cterm=underline gui=underline guisp=LightGrey

hi default link DiagnosticVirtualTextError DiagnosticError
hi default link DiagnosticVirtualTextWarn DiagnosticWarn
hi default link DiagnosticVirtualTextInfo DiagnosticInfo
hi default link DiagnosticVirtualTextHint DiagnosticHint

hi default link DiagnosticFloatingError DiagnosticError
hi default link DiagnosticFloatingWarn DiagnosticWarn
hi default link DiagnosticFloatingInfo DiagnosticInfo
hi default link DiagnosticFloatingHint DiagnosticHint

hi default link DiagnosticSignError DiagnosticError
hi default link DiagnosticSignWarn DiagnosticWarn
hi default link DiagnosticSignInfo DiagnosticInfo
hi default link DiagnosticSignHint DiagnosticHint

Commenting out the content does not cause the pacman install to reproduce.

:shrug: :shrug: :shrug: :shrug:

rktjmp commented 2 years ago

Fixed in 3df0790319b0985d04e2f09fe879b6c2b15692f2.

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 commented 2 years ago

Thanks a bunch!