Add support for xterm colors

[Granddave]

I came across this when configuring Tmux. In Tmux you can use either white, #ffffff or colour15 to indicate white (possibly more ways). Using the last method does not show any color with nvim-colorizer.lua.

After some googling it seems like the colourNNN is a way to denote the xterm colors.

Tmux supports using both the American (color) and British (colour) spelling.

More information:

• https://superuser.com/questions/285381/how-does-the-tmux-color-palette-work
• https://github.com/guns/xterm-color-table.vim/blob/master/plugin/xterm-color-table.vim
• https://www.ditig.com/publications/256-colors-cheat-sheet

[catgoose]

Yeah I see the color names returned from vim.api.nvim_get_color_map() are the xterm color names. It would be easy to support colorNNN or colourNNN via a lookup table like how the tailwind names functionality works.

[Granddave]

Would be great!

Also, two other things I noticed regarding xterm colors;

1. red maps to #FF0000 instead of the terminals colorscheme. That behavior makes sense in most cases, but in this case when we're talking about xterm colors red relates to the xterm color red, i.e. colour1. Thoughts on having an option to use the xterm table instead of RGB colors? For example name_mode = "xterm|css" or whatever.
2. This is very much related to the first point; bright$COLOR, e.g. brightred is not recognized as colour9. I guess that would be relatively easy to map if above is implemented.

I'm just dumping my mind here, things that could be nice to have :)

Thanks

[catgoose]

Would be great!

Also, two other things I noticed regarding xterm colors;

1. red maps to #FF0000 instead of the terminals colorscheme. That behavior makes sense in most cases, but in this case when we're talking about xterm colors red relates to the xterm color red, i.e. colour1. Thoughts on having an option to use the xterm table instead of RGB colors? For example name_mode = "xterm|css" or whatever.

According to https://www.ditig.com/publications/256-colors-cheat-sheet red maps to #FF0000.

2. This is very much related to the first point; bright$COLOR, e.g. brightred is not recognized as colour9. I guess that would be relatively easy to map if above is implemented.

Do you have an documentation about bright$COLOR? All I could find was information similar to what you linked in your original post.

I'm just dumping my mind here, things that could be nice to have :)

Thanks

Parsing for say color5 should be easy:

I think I would want to have an xterm configuration key similar to names and allow for enabling american/british spelling.

===

Presently I am playing around with a configuration key to configure the names parsing behavior:

local plugin_user_default_options = {
  names = true,
  names_opts = {
    lowercase = true,
    camelcase = true,
    uppercase = false,
    strip_digits = false,
  },
  names_custom = false,
...

This effectively allows for controlling highlighting blue, Blue (from vim.api.get_color_map()), BLUE. Maybe there can be some customization like this for the xterm configuration key.

[Granddave]

Right, this is an interesting rabbit hole...

Seems like red maps to #FF0000 as you said in the HTML world, but in the ANSI world red is some kind of color group that can have different intensity. In the terminal red is often 50% red (colour1) and to get "full" red you set the intensity escape code (colour9).

I don't fully see the connection between HTML colors, Xterm colors and ANSI escape codes though...

• https://en.wikipedia.org/wiki/ANSI_escape_code#3-bit_and_4-bit
• https://stackoverflow.com/questions/4842424/list-of-ansi-color-escape-sequences

What I was after in my first message above was that Neovim would show what my actual colour1 in the Tmux config is according to the colorscheme of the terminal emulator, i.e. cterm=1 (see :h ctermfg).

Maybe that could be an option? An option to map colourNNN to cterm colors instead of literal hex codes?

Sorry for this ramble mess of text.

---

Yes, option for ignoring camel case etc could be good!

[catgoose]

Ramble on :D

It looks like we can set highlight by cterm values:

• https://neovim.io/doc/user/api.html#nvim_set_hl()

Currently hex values are being used to create highlights

nvim-colorizer.lua/lua/colorizer/buffer.lua

Lines 67 to 78 in 3437b6b

	highlight_name = make_highlight_name(rgb_hex, mode)
	if mode == "foreground" then
	vim.api.nvim_set_hl(0, highlight_name, { fg = "#" .. rgb_hex })
	else
	local rr, gg, bb = rgb_hex:sub(1, 2), rgb_hex:sub(3, 4), rgb_hex:sub(5, 6)
	local r, g, b = tonumber(rr, 16), tonumber(gg, 16), tonumber(bb, 16)
	local fg_color = color.is_bright(r, g, b) and "Black" or "White"
	vim.api.nvim_set_hl(0, highlight_name, { fg = fg_color, bg = "#" .. rgb_hex })
	end
	hl_state.cache[cache_key] = highlight_name
	return highlight_name
	end

but if there were a xterm parser it could return the correct cterm values, or maybe hex and cterm depending on configuration. I'm not really sure at the moment, as you said it's a bit of a rabbit hole, but I'm willing to look into it after a few other things are added and cleaned up in this plugin.