Hex colors slightly off?

[mcchrish]

local lush = require "lush"

local c = lush.hsl("#fbf1c7")
print(c.h, c.s, c.l, c.hex) -- 48 87 88 #FBF0C6

Should still be #fbf1c7 instead of #FBF0C6.

[rktjmp]

See #59, to my eyes it is not an issue in practical use. If you can find lossless conversion code, that is actually lossless, I am open to it.

[mcchrish]

I didn't see there's a length discussion about it already. Indeed, in practical use it doesn't really matter that much. I only notice since I'm comparing them side-by-side and looking at them intensely.

[rktjmp]

Yeah I wish there was an easy fix, maybe one day I will have time to look into it again. As I said in that other thread, I would bet in real terms, the differences between monitors and terminal rendering pipelines probably has a way more noticeable impact than the fractional differences in color codes. Probably healthiest to not sweat over it too hard.

[mcchrish]

I just remembered, is it possible to store the original hex somewhere (maybe just a key { orig_hex = "#fffff" } in hsl table) and then use it when compiling? That might be a possible work around.

[rktjmp]

Technically yes, it could do dirty tracking but the added cognitive/code/maint weight is debatably worth it IMO.

Lush "works in HSL" since you can't do any of the operations (li, ro, etc) in hex, not in a way that makes sense. You could instead define (and pick) your colours in HSL and then there is no smudging 😄.

It's debatable how useful the operations are to most people. Lush grew kind of as an experiment in my own workflow, but really most themes are done "colors-down" via a palette, not "colors-out" via a base → operation. That's been a standing annoyance for me, Lush lacks good palette-focused tooling for now.