Repository: neovim
Issue: More default highlighting groups
Labels: enhancement,defaults,needs:discussion,highlight

### Feature already in Vim?

No

### Feature description

Hello everyone, I would like to propose the addition of more default highlight groups to Neovim

## Motivation

Over the years more and more plugins have been adding their own highlight groups and colour schemes have been implementing these custom groups to make the plugins look fancy. However, this creates a problem where themes now have to add all sorts of extensions, which are potentially redundant because different plugins use different names for what should be the same highlight group. This creates additional maintenance burden for theme authors and users now have a huge checklist they need to cross-compare with their plugins list.

For this reason I propose adding more default highlight groups to Neovim. These groups should have reasonable fallbacks defined in Neovim itself.

## Proposed highlight groups

### Rainbow

Rainbow parentheses are an obvious one, but rainbow colours are useful for any context in which we want to put different levels or markers, such as indent guide lines. Rainbow groups could also be used by some sort of manual highlighting plugin to create different groups of highlighting.

#### Proposal

I suggest going with the seven modern colours:

- `RainbowRed`
- `RainbowOrange`
- `RainbowYellow`
- `RainbowGreen`
- `RainbowCyan`
- `RainbowBlue`
- `RainbowViolet`

https://en.wikipedia.org/wiki/Rainbow#Number_of_colours_in_a_spectrum_or_a_rainbow

Colour schemes do not need to implement the exact colours, it is up to the
theme which colours will actually be used. The only requirement is that the
colours gradually transition (i.e. `RainbowOrange` is somewhere in between `RaindbowRed` and `RainbowYellow`) and that the colours loop around (i.e. `RainbowViolet` is between `RainbowBlue` and `RainbowRed`).

It is up to plugins whether they want to use these colours in their gradual
order or whether they prefer to order them so that the colours differ.

#### Precedent plugins

- Any rainbow plugin (e.g. https://github.com/p00f/nvim-ts-rainbow)
- https://github.com/lukas-reineke/indent-blankline.nvim


### Mode indicators

Neovim can display the current mode via the `showmode` option, but doing so requires on extra vertical line an I need to move the focus of my eyes to the lower-left corner. We can display the current mode in the status line, but I still need to move my eyes. A visual highlight of the mode indicator allows me to immediately tell the current mode from the corner of my eye; my peripheral vision cannot detect text, but it can detect colour.

Status line plugins already offer a status indicator component with coloured
background, but the highlight groups are non-standard. A standard group would allow consistency across themes and users could apply the group to other status line components like the line number and save some horizontal space.

#### Proposal

Here is a compact proposal:

- `ModeIndicatorNormal`
- `ModeIndicatorInsert`
- `ModeIndicatorReplace`
- `ModeIndicatorVisual`
- `ModeIndicatorSelect`
- `ModeIndicatorCmd`

Alternatively there would be an indicator for every possible mode that can be returned by the `mode()` function, but then the other highlight groups should link to one of the above by default.

#### Precedent plugins

- Any status line plugin out there

### Panels

A panel is a window whose buffer is not an actual text buffer, but some sort of UI, such as a file system tree. Panels cannot be edited and tend to have their own special bindings. Since they are not editable text they should be displayed with a subdued (darker? lighter?) background.

#### Proposal

- `Panel`

#### Precedent plugins

- Any tree side panel plugin
- https://github.com/rcarriga/nvim-dap-ui

____________

These are the highlight groups I can think of, but I am sure there are many others. Please let me know what you think and what should be added. The groups should be as generic as possible and not tied to a particular plugin, even if only one plugin will use that group. We should limit ourselves to actual cases from existing plugins, that is why for each proposal I have a list of precedent cases.