Closed brunnre8 closed 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.
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
?
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 :wink: )
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:
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).
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...
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?
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 Running 0.7.2
wont repro on my machine but 0.8.0
will.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 ---
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:
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.
Thanks a bunch!
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](https://user-images.githubusercontent.com/16165454/176660300-a6e721cd-f172-435a-8c42-fa7039de3cd1.jpeg)
lush.nvim main:![main](https://user-images.githubusercontent.com/16165454/176660403-a0c479b5-3e98-4e35-9cca-dfcbb7d29275.jpeg)
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.