Enabling to work with a 256 color terminal

[jomade]

Summary

This pull-request enables the gruvbox plugin to display close colors also on a 256 color terminal. This is e.g. the case for the Terminal that is part of MacOS which does not support RGB/24Bit color/termguicolors. The only thing that the user needs to do is ensure that termguicolors is set to false on a 256 color terminal.

Use case

Users that cannot or don't want to change their terminal application that only supports 256 colors to a terminal that supports 24Bit colors but still would like to enjoy the gruvbox color scheme. So far, the colorscheme is not usable on terminals that support and this change would make it much easier for users that are in that situation to make use of the plugin.

Implementation

Similar cterm indexes are selected to match the 24bit colors as close as possible for all colors of the palette (this was automatically done with a python script, which can be supplied if desired). The palette is then extended with these indexes. At the end, the palette entries are expanded prior to the call to the vim api.

Side effect of the proposed changes

To work in a 256 color terminal, termguicolors needs to be false. Since it is currently forced to true in the plugin code, this is removed (Line 1242). Termguicolors thus now needs to be set outside of the plugin eg. in the plugin configuration.

Screenshots

Screenshot showing colors on a 256 color terminal prior to change (left iTerm2 with 24bit color, right Terminal 256 colors):

After change: Comparison of colors 24bit enabled (left on iTerm with vim.o.termguicolors=true) and 256 colors (right Mac default Terminal with vim.o.termguicolors=false).

Final remarks

@ellisonleao, let me know what you think and whether there would be changes needed before this could be merged.

I'm looking forward to your and others feedback!

[jomade]

Sorry, I see this causes a crash when used together with fzf-lua. In addition there might be an issue with overrides. I will try to come back when/if I am able to figure that out.

[jomade]

Reopen as the bug is fixed in the feature branch now.

[ellisonleao]

do we need to explicitly set it to "NONE" if they are empty?

[jomade]

If the entry is empty/nil it will not be set.
If it is not nil, then it is evaluated if a colorname or "NONE" was supplied and expanded or not dependent on the content.

This clause is introduced since there is one entry in the palette "@none" where fg="NONE". That would cause the lookup to fail as "NONE" is not a color name. However that would be a different way to resolve that.

Does that make it more clear? Thanks for looking into this!

[lxv]

isn't it easier to read this way? --

Suggested change

	dark0 = { ["gui"] = "#282828", ["cterm"] = 235 },
	dark0 = { gui = "#282828", cterm = 235 },

[lxv]

1. This patch removes dark0_hard for whatever reason.

2. why not structure this as:

Gruvbox.palette = {
  gui = {
    dark0_hard = "#1d2021",
    dark0 = "#282828",
    ...
  },
  cterm = {
    dark0_hard = 235,
    dark0 = 235,
    ...
  }
}

[jomade]

Thanks for reviewing.

0. Readibility without brackets: I fully agree. Sorry, it is the first time I'm coding lua and I thought for some reason that the brackets ought to be there. Anyhow, corrected now in the most recent commit.
1. removal of dark0_hard was unintentional, thanks for spotting that. Corrected in the most recent commit.
2. There were three reasons for it in my mind. First, it's supposed to be the same color, so it feels natural to have one key that then is used to access the same color for two different ways to configure the color. Second, the names are used eg. in the color groups. I felt it would require many more changes in the code and would result in a lot of overhead code. Now it the main logic is the same and at the end, for all highlights, a conversion expands into gui or cterm. The third reason is maintainability. It is much better to have the two values close to each other in the code. If you change the gui value, you see you need to adapt the cterm value as well. What would be your argument for changing it that way?

[lxv]

The advantage of the proposed structure is a vast simplification of the patch: the entire expand_colors_in_highlights() becomes unnecessarily as the correct palette can be returned from get_colors() depending on the value of vim.o.termguicolors, everything else (excluding your patch in L1242) can remain the same as before.

[lxv]

@jomade Here's what I could come up with -- lxv@eae39ed -- I'm not entirely sure if it's that much better than your version. It's disappointing that unlike vim_get_hl_by_name() which allows users to specify GUI/TUI flag in the 2nd arg, nvim_set_hl() doesn't support that (ref: https://github.com/neovim/neovim/blob/master/test/functional/api/highlight_spec.lua)

[lxv]

NVM, my version breaks runtime changes termguicolors <-> notermguicolors because it only has access to either cterm or gui color value at a time. I'm sorry about the noise.

[jomade]

No worries.
Btw, I know see that I probably can make the expansion function more compact. Let's see if I can get that done on one of the next evenings. Sth along the lines (not tested):

local function expand_highlight_prop(hl, prop)
   if hl.[prop] == nil then return end
   if hl.[prob] == "NONE" then
     if prop != "sp" then 
          hl.["cterm"..prop] = "NONE"
     end
     hl.[prop] = "NONE"
   else 
     hl.["cterm"..prop] = hl.[prop].cterm
     hl.[prop] = hl.[prop].gui
   end
end

And then call the function for "fg", "bg" and "sp".

[jomade]

See my recent upgrade. I have compacted the code as outlined here (minus the bugs in the displayed code...)

[ellisonleao]

why are you removing this?

[jomade]

I understood this line as it will enable termgui-options without possibility for the user to disable it - is this correct?
Nvim will ignore the cterm-colors if the option is set. So for the 256-colors, the option needs to be disabled.

[jomade]

Do you have another proposal how to allow for the user to switch off termguicolors?

[ellisonleao]

I understood this line as it will enable termgui-options without possibility for the user to disable it - is this correct?

that's correct but I am also worried about the users who already have the plugin in place who doesn't have this enabled yet. I will see if we have a better way to check this

[jomade]

That's a valid concern. I also think it should be default with termguicolors - that's the future anyway.
Is it possible to get it in as a config variable? I have not fully understood how the configuration system works ... But a config switch to turn on 256 colors and disable the automatic termguicolors could work well.

[jomade]

See my most recent commit. I added a config option.