fix(colorify): clamp rgba to prevent invalid hex string

[StefanBartl]

Summary

This PR fixes a critical bug in nvchad.colorify.methods.lua where colors received from LSP via textDocument/documentColor were incorrectly converted from RGBA to hex strings.

The original implementation directly multiplied floating-point values without clamping or rounding, producing invalid hex strings such as #fe01fe01fe01, which caused runtime crashes when passed to nvim_set_hl() (see colorify/utils.lua: line #31).

What was changed

• Introduced a safe to_hex(r, g, b, a) function that:

  • Multiplies RGBA values with proper rounding (+0.5)
  • Clamps each component to the 0–255 range
  • Constructs valid 7-character hex strings of the form #rrggbb

• Replaced the direct string.format(...) call with this safe method inside the LSP color handler.

Why this matters

Without this fix, certain LSP servers (e.g. CSS, SCSS, Tailwind) may cause hard crashes when they return slightly invalid or unnormalized RGBA values. This bug is reproducible with color-aware LSPs (e.g. for CSS, SCSS, TailwindCSS, or Vue via Volar) that return fractional RGBA values.

Example Error

Error executing vim.schedule lua callback:
.../colorify/utils.lua:31:
Invalid highlight color: '#fe01fe01fe01'

Additional Notes

No visual or functional changes for users.

[siduck]

can you show me an example file

[StefanBartl]

Sure, happy to clarify!

Here’s a minimal code snippet that triggers the error in my setup:

example.lua:

local color = {
  first = 0.9,
  second = 0.5,
  third = 0.7,
  fourth = "#122112"  -- here it breaks!
}

I’ve experimented a bit and found that the error only occurs in Lua files. Attempts to reproduce it using .json or .css files did not trigger the error.

Here is the full error message I get:

Error executing vim.schedule lua callback:
...ta/Local/nvim-data/lazy/ui/lua/nvchad/colorify/utils.lua:31: Invalid highlight color: '#11ee20df11ee'
stack traceback:
  [C]: in function 'nvim_set_hl'
  .../colorify/utils.lua:31: in function 'add_hl'
  .../colorify/methods.lua:68: in function 'handler'
  ...m Files/Neovim/share/nvim/runtime/lua/vim/lsp/client.lua:679: in function 'fn'
  vim/_editor.lua:366: in function <vim/_editor.lua:365>

Since this only happens in Lua files (only testes lua, css and json!) and the LSP client appears in the stack trace, I suspect this results from some interactions between the Lua LSP (e.g. lua_ls) and nvchad.colorify, maybe some LSP or UI features parse and render hex strings, including unexpected values.

This PR solves the issue with a small helper function that ensures all RGB(A) values are clamped to the valid 0–255 range before being converted into a hex string. This prevents invalid hex values like #11ee20df11ee from being generated during processing.
To be clear: this malformed hex string does not exist in my code or in any theme file directly. Rather, it is "constructed dynamically at runtime", maybe as a result of the alpha component being incorrectly applied or multiplied, possibly due to an unexpected LSP response or internal state.

I guess that once such an invalid string is passed to nvim_set_hl, it causes a hard runtime error and breaks the colorify feature. Clamping prevents this entire class of crash.

I’ve also attached a ZIP file with the Lua files and screenshots showing the error, taken from my usual production setup.

Just to note: I've confirmed the issue is not related to noice.nvim (even though I use it in the screenshots); it still occurs without it.

Let me know if I can help reproduce it further!

ColorifyPR.zip

[siduck]

@StefanBartl why closed and deleted it? 😨

[StefanBartl]

@StefanBartl why closed and deleted it? 😨

Hi @siduck,

I closed the PR because there was no reply on my last comment and it had been inactive for a few months, so I assumed it might not be relevant anymore or perhaps was being handled differently internally. There was no intention to drop the contribution — just to keep everything clean.

If the fix is still useful, I’d be happy to reopen or recreate the PR.

[siduck]

@StefanBartl i was inactive due to work 😓 , please keep the PR opened. i will merge it when I'm free, probably this weekend.

[StefanBartl]

@siduck alright!

Sadly this PR was closed and the repo deleted from my system, so i had to open a new one: #520