Improving themes

[littlelevi]

I'm porting the "Doom One" theme for Helix and have some suggestions and comments.
Also I know that some of them do not conform to the TOML specification. But I think it is still worth leaving these thoughts, even if they were never intended to be implemented

Nameless key values

Lets consider this case:
"ui.background" = { fg = "white", bg="black" }

Most of us intuitively know that the convention is to first input text color, then the background color.
In that case, it seems that a much cleaner and less verbose solution would be:
"ui.background" = { "white", "black"}

conclusion: Named keys only make sense if we want to reverse the order and first specify bg and then fg

It looks much clearer. Okay, but someone might ask, what if we only have one parameter, don't we have to name them ? Well, not necessary.
We could either leave only comma "ui.background" = {, "black"} but this might be little confusing, unreadable and go against practices that we encounter in most programming languages.
Basically we are telling parser, we don't want set this value. It's a nice idea to just leave the quotes blank, just as in empty strings or use some kind keyword signaling we want to inherit from upper ui scope
"ui.background" = {"", "black"}

Nameless table

The same problem applies to modifiers. Modifiers is TOML table containing additional styles, like "bold", "underlined" or "italics"

"comment"' = {modifiers = ["italic, bold"]}
At the moment, it is completely unjustified. There are no other tables that could fit into that parameter.
In that case, it seems that a much cleaner and less verbose solution would be:
"comment" = { ["italic", "bold"] }

Now, this looks much nicer.
Named tabled only make sense if we want to have many different tables containing unique set of styles, like custom effects (Which is more applicable to GUI) Here we are limited to only few terminal styles.

Variables

Very often we have one style and we would like to use it multiple times. Let's say we have such scenario. We have our default style with text and background color. We know we will use it quite often, lets say its UI style, as many TUI widgets elements like windows and popups look same we would like to bring some unification.

default = {"white", "black"}
ui.window     = default
ul.popup      = default
ul.statusline = default

That would be some much more readable and DRY. Especially in the case of simple styles wherever we want change whole theme changing 3-4 lines. The simpler the style the better this will work for us

CSS like cascading

The documentation clearly shows that Elements of Helix form a hierarchy. My first intuitive reaction was "aha! It must work like css" Unfortunately, it turned out not to be so. I expected having hierarchies for example. ui.text and ui.text.focus then if ui.text.focus is not set manually, it will inherit the style from ui.text

But there is still not enough to fulfill wildest dreams

This might be bit controversial and debatable. So this is just my opinion, although I do not know exactly what tools should be adopted in order not to over complicate it.

Generally, the more I deal with styling different applications, the more I am convinced that styles should be in code, rather than written in serialized data format. In fact, all three problems mentioned earlier are easily solved by using a programming language instead of having to hack TOML or craft custom parser which will never be the same. It will always be missing something. The demand for new features like this is likely to grow.

Gains

While adopting programing language for styles will gain the editor for free features like imports, a way to split large file into small ones. Fine error checking capabilities(which is not easy at all, especially as the parser complexity grows) Possibility to reference other styles and retrieve its value. Inherit from them.
Refer to some plugins visual elements and import it, calculate colors and many more.

I was against it in the past, but I saw what Emacs can do and I changed my mind. Unfortunately, Emacs is quite a piece of f spaghetti. Yet I must say its still impressive what that spaghetti can do and how flexible it is.

Besides styles are not only colors, style are also Unicode glyphs, templates ,elements positions, relations like margins, padding, ncurses widgets styles, different types of borders and its corners and so on.

In fact, in this case, style would be specialized form of a plug-in. The only thing is needed is an API that will allow to conveniently interact with the elements of the editor. Which may not be difficult at all. It is possible that some lightweight wrapper for ncurses (or every other library like tree-sitter) would be enough to roll out basic functionality quite fast. As soon as Helix will have the infrastructure to write plugins.

In the future, handling the graphic front end is a completely different story and presents even more possibilities and challenges. Nevertheless, it would be worthwhile if some styles could be inherited and allowing for fast re usability. Which would come down to importing data structures. What is another argument for such a solution

The only cost additional "cost" is in this case is little more complexity of the style description and the need to learn a language that is usually more complicated than the serialization data format. On the other hand, in most cases the work would mainly be to fill the structure/class with data, which should not be different from TOML. Constructs like symbol substitution are also quite intuitive, more complicated things like custom functions can be in additional files and you don't need to touch them.