Consider usung HSLUV rather than HSL about lush.nvim

[harrygallagher4]

Well, that was bizarre timing. This comment I just left happens to be extremely relevant to this issue.

Here's a gist with some of the work I've done on integrating lush.nvim + hsluv. I can add my colorscheme.lua to the gist if necessary but the screenshots pretty much cover the interesting bits so far

[rktjmp]

I have pushed an experimental branch that supports the HSLUV space (actually it's living in the same one as mix (https://github.com/rktjmp/lush.nvim/tree/feat-mix because I didn't want to manage two change sets.)

This is experimental and things might change. I went feet first without any tests so...

Usage:

hsluv = require('lush').hsluv -- or require('lush.vivid.hsluv')

-- doesn't this look familiar?
hsluv(100, 30, 20).ro(10).li(10).mix('black')

---

HSL won't ever be replaced with HSLUV because:

1. It would break existing themes since the colorspace is obviously intentionally not a 1:1 match
2. HSL is already "weird" for most people, probably 4th most popular behind #RRGGBB -> rgb -> hsb -> hsl, having a niche of a niche feels like a poor choice, even if it's technically superior. It also limits external tools since everything would have to be passed in as #RRGGBB from palette generators or image tools (you already have to do this half the time because HSL has poor support).

I hope that separating it out in its own color library lets people who know and understand it use it, but keeps backwards compatibility.

---

Note: Lush is entirely independent from the color system.

Lush takes whatever you stick in fg/bg, it just expects to be able to concat it with a string and get a good "vim value" (rgbhex or colour name) back when it compiles.

This means if you want to explore say, the L*a*b* colorspace, you just need to wrap whatever value you pass to lush's fg/bg keys in a meta table that responds to tostring() and concat().

---

The one big downside appears to be the speed compared with HSL/RGB, but I've not noticed any issues while using it interactively, so not sure if this just means "too computationally expensive to be widely adopted in the 1970s and become part of legacy computing",

Somewhat contrived test:

count = 100000
t_a = vim.loop.hrtime()
for i=0,count do
  local x = hsl(100, 50, 50).ro(10).li(20).mix('black', 50)
end
t_b = vim.loop.hrtime()
n = t_b - t_a
print("hsl n=count: " .. n .. "ns total " .. n / count .. " ns avg")

t_a = vim.loop.hrtime()
for i=0,count do
  local x = hsluv(100, 50, 50).ro(10).li(20).mix('black', 50)
end
t_b = vim.loop.hrtime()
n = t_b - t_a
print("hsluv n=count: " .. n .. "ns total " .. n / count .. " ns avg")

hsl   n=100000: 1242679500 ns total 12426.79500 ns avg
hsluv n=100000: 1222371229 ns total 12223.71229 ns avg

0.012223 ms for a "semi complex" chain, I wouldn't worry about it. (HSLUV is slightly faster because it get's a warm cache. Flipping the order flips the results.)

[davidscotson]

Hey, just wanted to say I've been using this on the feat-mix branch since that was created and it's all worked well for me, with no issues as I've been fiddling with my theme ideas on top of it. The creation of (semi-)auto-generated color schemes that are visually pleasing seem much simpler, and it works well with the manual tweak-it-and-see-what-happens loop too as the values are little more human friendly.

[rktjmp]

Great! Basically just pending me writing some tests that are more specific to the "vivid" refactor before I can put it mainline. I will ping this thread when I finally get to that.

[rktjmp]

Merged mainline d3071c7.