Great. Another thing I need to work around. ๐
The #evolution of modern Linux feels more like a #devolution for me sometimes.
Latest entry in my personal list is @neovim which now uses the ancient #Vim leftover highlight configurations guifg and guibg by default, messing up modern colorschemes in Lua-only setups.
@dirk How are guifg and guibg "ancient leftovers"? They've been used for 24-bit color in supported terminals for years and are very much still relevant.
Sounds like your problem is something else entirely.
@scy Its 2024, I just donโt want anything non-Lua in my config ๐
Using those names and configuration just feels ooooold. Like literal โ15 years agoโ old. I am pretty sure if I search old backups Iโll find my config from back then using this โฆ Nowadays my whole highlighting setup uses #treesitter and its groups. So please bear with me when I call it ancient, to me it feels ancient.
Well, anyways.
I just wonder how to set that in Lua, without wrapping legacy highlight definition syntax in a vim.cmd? I need to set both of them to 0 to restore the original behavior of pre-0.10 #Neovim.
See attached images. The darker one is the new default, the lighter one is what I had before (code shown is completely irrelevant and has to be seen as lorem ipsum here).
The new behavior of Neovim 0.10 is reverted with this, directly entered at the command line.
๐๐ช๐ณ๐ฌ
scy:highlight Normal guifg=0 guibg=0
Where does it take the wrong colors from, anyways? Neither the color used for the @none group, nor the color used for the background are configured anywhere in my whole setup. Not in the colorscheme, not in the config, not in my terminalโs setup.
