red colour meaning

[bugabinga]

In my opinion, falcon is a lovely colour pallete. I wonder however, about the use of red for mundane values in the syntax schemes.

To me red means "critical", "danger", maximum attention". As such it should be reserved for errors and such.

What are your thoughts?

[fenetikm]

I have had a similar thought - maybe I was just waiting for someone else to bring it up too :) The general idea of creating a type of "semantic" or "meaning" based palette is quite interesting although I feel like for that to really work well the syntax highlighting rules would need to be more consistent across languages.

I'll take a look at some alternatives.

[bugabinga]

There are two semantics here we can distinguish:

• the meaning of colours ( red == bad, green == good)
• the meaning of syntax styling (bold, italics, colour, underline, etc.)

The first case is tough, because colour codes change relative to country/culture/context. However, it is my belief that at least those two examples, red (negative connotation) and green (positive connotation), have become universal in the context of computer UIs.

The second case is tough, because it concerns subjective preferences. Different people prefer different levels of contrast and colour palettes. They also prioritize syntactical elements differently. Here is an example of an issue I have with most modern syntax themes:

-- something important
local hello = 'supson'

Most themes will de-emphasise the comment and emphasize the keyword. However, in my view, this is totally backwards. My preferred order of importance is: comments, variable names, values.

-- something important local hello = 'supson'

I have left out colour to keep the example simple (and GitHub markdown does not allow it). Notice the following: The most important things (in my view) jump out at you while scanning the text (bold). Second most important things are easy to find, when I am looking for them (italics). The rest fades into the background.

The general idea of creating a type of "semantic" or "meaning" based palette is quite interesting although I feel like for that to really work well the syntax highlighting rules would need to be more consistent across languages.

Can you expand on this? Is the problem specific to vim and its language definition files?

I think true semantic highlighting of code is sadly out of scope right now. Here is an example of what eclipse can achieve for Java:

var yo = new Integer(10);
System.out.println(Integer.toHexString(yo+5));

The syntax highlighter of eclipse can highlight the yo as bold/red or whatever because it detects the auto-unboxing (automatic conversion of a heap based value to a stack based value), which is considered dangerous in Java. This kind of highlighting is not easy to achieve in vim today; especially not for multiple languages. Maybe once neovim integrates treesitter (https://github.com/neovim/neovim/pull/10124) that story will be different...

---

To be clear, I am not saying you should change this theme according to my preferences as explained above. It is your theme, you should like it :)

But this is food for thought and maybe there is a way to achieve some nice customizability like for example monotone does:

let g:monotone_emphasize_comments = 1 " Emphasize comments

Personally I would like a setting akin to:

let g:falcon_importance_order = ['Comment', 'Identifier','Value',...] " I do not actually know the names of vim syntax elements, but whatever vim uses could go in here

[fenetikm]

Thanks for your thoughtful comment.

Yeah, the whole "comments are less important than code" is almost an editor / IDE trope (if such a thing makes sense). Another scheme that flips that is this one which you might find interesting. I found that from this rather interesting blog.

One problem that comes to mind around comments is that some are important and others aren't. e.g. comments that are present to generate documentation in my opinion are usually less important than inline comments above a hairy bit of code.

Regarding my comment around highlighting rules and consistency, I was clumsily referring to how, for example, in one language a boolean keyword would have a separate highlight group and in another it doesn't.... or even "worse" when tokens get diametrically opposing (from a semantic point of view) highlight groups. At a guess, perhaps this is why some colour schemes then don't bother going to that level and just colour what is consistent across syntax programming rules e.g. comments, non-comments, values. The problem isn't specific to Vim per se - it's a general problem around how syntax highlighting works in any editor that supports multiple languages. As you mention, projects like tree sitter, similar to what language servers have done for intelligent completion, will hopefully go a long way for helping with more consistent highlighting even if that consistency is then average across editors / IDEs but at least it could mean colour schemes could come with the syntax highlighter engine and make it easier for people to create schemes.

I agree with a lot of what you are saying and have had similar or the same thoughts over the course of creating this colour scheme - thank you for the validation! Sadly, at this point, I feel like the only way to get something that would meet both our needs, especially along the lines of "importance" or whatever axis one would like to use, would require writing a program that would allow dynamic scheme generation based on rules, perhaps even a colour scheme DSL which I personally don't have the time for. At least estilo, which my colour scheme leverages, let's one do some basic "update this palette here, and then generate a bunch of stuff" edits with relative ease which is the main problem when first getting going with creating a colour scheme. At the time, I chose to use it since it seemed to give the greatest bang for the buck as opposed to generating all the highlight groups by hand.

Having said that, I will have a think about what I could drop into the plugin file that might allow at least some minimal customisation around some highlight groups, comments being a good example.

Either way, I think I will definitely change the red that is used - will try some things over the next few days.

[bugabinga]

Sadly, at this point, I feel like the only way to get something that would meet both our needs, especially along the lines of "importance" or whatever axis one would like to use, would require writing a program that would allow dynamic scheme generation based on rules, perhaps even a colour scheme DSL which I personally don't have the time for.

Don't be! I can steal/fork this theme anytime. Does estilo handle all the covered programs?

Yeah, the whole "comments are less important than code" is almost an editor / IDE trope (if such a thing makes sense). Another scheme that flips that is this one which you might find interesting. I found that from this rather interesting blog.

Maybe you associate those "tropes" with each other because IDEs tend to auto-generate a lot of useless comments (when measured by this stick), which might lead to developers wishing to de-emphasize them.

The duochrome scheme has a take on comments, that I find personally very appealing, because it recognizes the issue, that depending on whether I am reading or writing code, comments are of different importance (to me). This principle could be expanded from comments to other syntax elements as well. In the past I have ignored this train of thought, because I thought that would lead to a (at least) 2-variant theme. One for reading and one for writing. The problems with this idea are probably obvious to you (complexity, inconsistency and how do we even switch between variants...). However, duochrome has opened my eyes to the possibility of a middle ground approach here. I will have to think some more about that :)

The blog as whole; is a real head-scratcher, pretty fun.

[fenetikm]

Unfortunately estilo only covers Vim - I have thought about adding in support for other programs (e.g. VS Code, terminals, terminal tools, highlight, bat etc.) which shouldn't be too hard but again... one day, maybe.

Glad you find the duochrome theme interesting. I like the idea too and I think if I create another theme it would be inspired by that way of thinking.

Back to the change of red :)

I have now made the following alignment:

• Constants are light gray, bold
• Booleans are light gray
• Numbers are normal gray

Which makes sense to me? What do you think?

[bugabinga]

I welcome that direction. What made you distinguish Booleans from Numbers?

I would have to see bold comments in action to decide if bold is too much, since most languages have a convention to spell them UPPERCASE, which already makes them visually distinguishable.

Unfortunately estilo only covers Vim ...

Wow, sounds hard to keep all those programs in sync...

[fenetikm]

My thinking is that booleans are more abstract / conceptual than numbers - i.e. false is usually translated to zero (0)... and constants are one level up again the conceptual tree being defined by the programmer (as opposed to the language).

That's a reasonable point about uppercase for one to consider. In my personal setup I use a semi-bold font instead of a bold font since I found bold too heavy.

[fenetikm]

...and I am going with your idea of making boolean the same as number. After trying my approach for a while I found it too much. In the process I also tweaked null highlighting to add in italic. Feels right.

[fenetikm]

@bugabinga you might like this video I just found https://www.youtube.com/watch?v=l1b7Da2DnPo

[bugabinga]

I did :)

I was aware of the font, the theme and even his blog, but until recently never actually realized they are from the same author... Amazing brain sometimes.

Regarding themes, I generally agree with his stance. I think his dismissal of the semantic highlighting features (as found in IDEs) is premature.

Are you thinking about the next theme;)?

[fenetikm]

Hah spot on re

are you thinking about the next theme

Will let you know when there is something to try out :)