Normal highlight stopped having a value from nvim_get_hl_by_name api

[oblitum]

After latest changes, this weird thing started to happen:

:hi Normal
Normal         xxx guifg=#724341 guibg=#FBF6F0 (using rosebones variant here)
:echo nvim_get_hl_by_name('Normal', v:true)
{}
:lua print(vim.inspect(vim.api.nvim_get_hl_by_name('Normal', true)))
{
  [true] = 6
}

I have no idea why, maybe it's a nvim bug (I'm on 0.7.0). Throught this nvim_get_hl_by_name, I'm used to pick zenbones' Normal highlight foreground value to set up colors for other stuff, but now I'm getting nil even though hi Normal shows it as non-nil. Not much an idea what's going, but since I'm solely hitting this from zenbones, I'm reporting it here first for a help.

[oblitum]

If I go to rosebones.vim, copy the line with highlight Normal guifg=#724341 guibg=#FBF6F0 guisp=NONE and paste it into command line for execution :highlight Normal guifg=#724341 guibg=#FBF6F0 guisp=NONE, then nvim_get_hl_by_name behaves as expected, so I dunno why this isn't happening anymore after :colorscheme rosebones.

[oblitum]

Issue might be in lush v2 (which I require). Reverting 7054d8cebbfc0f7f556484ba6091d0eb0d1daf26 and lush to v1 removes the issue.

[oblitum]

cc @rktjmp.

[mcchrish]

It might be related to this too: https://github.com/neovim/neovim/issues/18024

[rktjmp]

If the colors are getting applied, visually, which from what I can see they are, then I think it's outside of Lush's purview and probably #18024 or some inconsistency in the internal API that appears depending on how you set the highlight.

Lush's interaction with nvim_set_hl is super minimal, if the spec compiles OK, we just get the reduced data and send it along. So if it is visually OK in the editor then it applied cleanly and its out of Lush's hands.

As seen in this comment, Normal is a somewhat special group and perhaps thats why it's mucking up internally.

I tried a few things:

• Avoiding re-applying Normal in the above linked code
• Adjusting keys to foreground over fg
• Setting Normal to colors from another group (ie. trying "known gettable" fg/bg values)

Without any effect.

FWIW, you can get the colors directly from Lush specs, even alter them, to get around the nvim bug:

local rb = require("rosebones")
print("As hex", rb.Normal.bg.hex,
      "Adjusted, as hex", tostring(rb.Normal.bg.sa(10)), -- tostring() calls .hex under the hood
      "As .r .g .b table", rb.Normal.bg.rgb)

[oblitum]

It might be related to this too: neovim/neovim#18024

Thx @mcchrish, that surely sounds like the original reason, which had eventually slipped here after some code changes.

FWIW, you can get the colors directly from Lush specs, even alter them, to get around the nvim bug...

Thx @rktjmp, I'll try that, although that makes my code less colorscheme generic, I'll now be tied to zenbones/lush goodies, but as I'm solely using zenbones as my colorscheme anyway, I guess it'll be fine.

Closing as this seems a nvim bug.

[rktjmp]

If you wanted, you could sort of use the exporters to dump zenbones to raw tables then import that into your own theme.

I think following the build steps here but instead of using the colors table with nvim_set_hl, just return them from the module. That would give you a "raw" table nearly identical to what you'd get from nvim_get_hl_by_name, except the colors would be hex strings instead of rgb which may or may not matter, or at least can be converted back to int values.

You'd be adding a manual-ish build step to your theme but probably not that bad, just have to periodically dump *bones when it updates. Then you could distribute it without the upstream requirements.

[oblitum]

@rktjmp heh, thx, but I don't want that, your first suggestion is already working fine for me, I'll stick to that until nvim bug is fixed.

[rktjmp]

Should be fixed in HEAD https://github.com/neovim/neovim/pull/18820

[oblitum]

@rktjmp cool! thx for digging that.