Rename/Recategorized "key"s of Theme

[GreasySlug]

Describe your feature request

When I create a theme, the "key" names may not match the color change location well and may have multiple contexts.
For example, "ui.text.focus" is not clear where the focus is, and "special" has multiple meanings, as shown here in #2380.

• rename “key” names
• categorized by context

Here is a list of "key "s that I think are not so good

• ui.background.separator ⇒ ui.picker.separator
• special ⇒ ui.picker.matched
• ui.popup ⇒ ui.popup.markup(or ui.markup.background?) and ui.popup.completion
• ui.menu.scroll ⇒ ui.popup.scroll(does menu have scroll?)
• ui.window ⇒ ui.window.borderline
• ui.background ⇒ ui.window.background (too much?)
• ui.help ⇒ ui.menu.help
• ui.text.focus ⇒ ui.picker.selected
• hint ⇒ ui.statusline.hint, ui.gutter.hint(or just "hint")?, and ui.window.hint(or ui.popup.hint)?
• info ⇒ same as above
• warning ⇒ same as above
• error ⇒ same as above

if ui.window is accepted

• ui.window(for fallback)
• ui.window.borderline
• ui.window.background(too much?)
• ui.window.inactive(in the future)

if ui.picker is accepted

• ui.picker(for fallback)
• ui.picker.separator
• ui.picker.selected
• ui.picker.match
• ui.picker.borderline

[the-mikedavis]

IMO it's not worth refactoring a lot of keys like this until we switch configuration languages. This would break all existing themes. We can fix the ones that live in this repo but any themes outside would need their ui sections rewritten.

[GreasySlug]

It is certainly a problem that all existing themes will be broken.
However, I believe that almost similar Issues will be created in the future.
For example, the picker is one of the most important features in Helix, and perhaps users want to customize their own themes.
Then I think it would be easy to cause inconvenience when they try to use like #2454 to change it.
So I think we need to refactor keys little by little.

[Omnikar]

IMO it's not worth refactoring a lot of keys like this until we switch configuration languages. This would break all existing themes. We can fix the ones that live in this repo but any themes outside would need their ui sections rewritten.

I wonder if it would be worth it to ship a sort of "migration tool" with any releases that bring breaking changes regarding configuration and themes, that would take in a theme or config file that works for the previous release and spits out a functionally identical theme/config file that's compatible for the new release?

[GreasySlug]

This is a linter #3234 , but I agree that it would be nice to have a support tool similar to this.
However, it could be superfluous for many users.