Access to the palette when defining overrides for highlight groups?

[pkazmier]

Is there a way to access the current palette when I specify my highlight overrides?

In most themes I use, usually highlight_overrides can be either a table or a function that returns a table of highlights. The key, however, is that the function is passed an argument with the current palette colors. Then one can override a highlight group using the logical palette names. For example, if I wanted to override Comment to use the current palette's fg.dim instead of the default (not that I want to do this, just giving an example):

  require("oasis").setup({
    highlight_overrides = function(c)
      return {
        Comment = { fg = c.fg.dim }
      }
    end
  })

Looking at the code quickly, this would be a trivial trivial change to theme_generator.lua:

	-- Apply user highlight overrides last (they take precedence)
	local overrides = Config.highlight_overrides
	overrides = type(overrides) == 'function' and overrides(c) or overrides
	for name, attrs in pairs(overrides or {}) do
		if type(attrs) == "table" then
			vim.api.nvim_set_hl(0, name, apply_styles(attrs))
		else
			vim.api.nvim_set_hl(0, name, { link = attrs })
		end
	end

Thoughts?

[uhs-robert]

I think this is a great idea! Your implementation suggestion would work, and you're right, it would be a trivial update to pass the current palette to the user. But... I also see some existing user experience issues around this area that should probably be addressed for the best experience.

The main issues I see are:

• Users need access to the current palette for highlight_overrides and palette_overrides.
• Users may want access to all colors for all colors and themes as well (i.e., use another theme's colors).
• Users will want auto-complete information for palettes.
• Users will want to customize these overrides globally, per theme, per light/dark mode, and per light intensity.
• If we are going to be adding auto-complete information for this area, then we may as well make a fully comprehensive types.lua document that provides auto-complete information for all user-facing functions and configurations.

---

What I am going to do is make an issue that contains all of these requirements. I will reference this discussion in that issue. I may have some time this weekend or Monday to tackle this request.

[pkazmier]

Wonderful! I look forward to whatever you come up with! I’ve been test driving your theme this morning and have really taken a liking to it. Very nice!

BTW, I’ll be submitting a PR for ‘mini.nvim’ support (hopefully this weekend too).

[uhs-robert]

Happy to hear that! Do you have a favorite variant yet? I am also curious what support mini.nvim needs. I haven't really played around with mini yet.

This was a very fun project for me; I still do some tweaks now and then. Don't forget to check out the Extras if you haven't already.

---

I just finished this update as well and closed #28. Can you update the plugin and let me know if it works on your end?

The config examples in the README have been updated for "Changing Palette Colors" and "Changing Colors for Highlight Groups". It's a little complex; there are many options to play with. You can pass a table or function to palette_overrides or highlight_overrides.

For example:

highlight_overrides = function(c, colors)
  ---@type OasisHighlightOverrides
  return {
    Comment = { fg = c.fg.dim },
    desert = {
      Comment = { fg = c.syntax.preproc },
    },
  }
end,

[pkazmier]

Thanks! Not at computer right now, but will test tomorrow morning.

[pkazmier]

Works great! Thank you for the fast turnaround! This just makes it so much easier to customize highlight groups using the same color palette of the theme without resorting to looking up RGB values. Thanks again!

[pkazmier]

For consistency, what are your thoughts about the function in each of the oasis/integrations/plugins integrations? Right now, it is provided the c argument, what do you think about also providing the second colors argument for access to the palette?

[uhs-robert]

That's an interesting question. I am not at my computer right now but, I think, providing the base colors may be a bit tricky to work with for plugin integrations. Might be easier just to stick with the palette for each theme as you can fine tune the colors for each one that way and handle the exceptions easier. The light themes are automatically generated from the palette but they aren't generated for all colors in the base. The palettes have also been tested for AAA WCAG compliance (or 6.5 at least unless it is a dim color intentionally) against each of the theme's backgrounds so they are safe to use within the context of each theme.

One of the trickiest aspects of this particular plugin is that there are 13 themes total (and 78 total variations with each light intensity). Each has its own unique primary color which makes global decisions very rare (e.g., using red on Sol, Canyon, and Rose is a real challenge). Oftentimes colors need to be tweaked slightly, other times greatly, and then there are situations where exceptions need to be made entirely to hit the minimum WCAG compliance. For these reasons, using the base colors is pretty risky so I opted not to do it. Unless a generator is involved (light themes, I just couldn't figure out how to do them otherwise 😂).

But if you think that using the base colors is beneficial then I also say go for it. A kitchen without sharp knives is not an easy place to cook after all, sometimes you need the sharp knife even if it is a bit dangerous. But it will likely involve a hefty bit of trial and error.