Closed mcchrish closed 2 years ago
See https://github.com/rktjmp/lush.nvim/issues/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.
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.
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.
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.
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 :smile:.
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.
Should still be
#fbf1c7
instead of#FBF0C6
.