feat: migrate to vim.api.nvim_set_hl()

[skewb1k]

Replace string-formatted :highlight command with the native Lua API vim.api.nvim_set_hl(). This change improves performance by avoiding command-string construction and enables full support for all keys supported in vim.api.keyset.highlight.

Breaking changes

This change breaks compatibility with user configs using the old format:

-- old
{ fg = "#fff", bg = "#000", gui = "italic" }

-- new
{ fg = "#fff", bg = "#000", italic = true }

The vim.api.keyset.highlight has not gui field and instead uses separate booleans (bold, italic, etc.). This also allows specifying multiple styles simultaneously, which was not easily possible with the previous gui string field.
This should be easy to update in configs, but it's worth calling out explicitly.

Config structure

This change also surfaces a broader design question:

While on_highlights will give users full control over all hl-group properties, the config’s styling-related options (bold, italic, etc.) feel increasingly limited—and possibly redundant.

My suggestion would be to:

a) Keep only a few top-level global toggles (e.g. italic = false, transparent = true) that apply across all groups

b) Drop the plugins section, which is already somewhat outdated and less reliable than editing highlight groups directly via on_highlights

Or another option that I see is to expose vim.api.keyset.highlight for each config style, so it will be not plugins.cmp.match = "italic" but plugins.cmp.match = { italic = true }. But it feels like aliasing already existing API of hl-groups.

---

Now that this is taking shape, it feels like a v2-level change. I'm uncertain about how best to approach backward compatibility:

• Attempt to keep the old format supported and mark it as deprecated?
• Or break it cleanly and ask users to migrate, given that the change is relatively minor and the new API is clearly better?

I’m leaning toward a clean break—most users likely won’t be affected much, and it would simplify the code and config model.

That said, I’d really appreciate your input and overall vision for this. I’m happy to adapt and move forward with whichever direction we choose.

[vague2k]

just occurred to me that this change would cause the colorscheme to only work on specific minimum version no?

[skewb1k]

just occurred to me that this change would cause the colorscheme to only work on specific minimum version no?

vim.api.nvim_set_hl() is available since version 0.5, which was released 4+ years ago. I believe it's safe to say that all users have it by now.

[vague2k]

lol i live under a rock haha