Manual overriding for theme precedence

[llakala]

As stated in the documentation, the rule for which theme key takes precedence is:

When determining styling for a highlight, the longest matching theme key will be used. For example, if the highlight is function.builtin.static, the key function.builtin will be used instead of function.

However, what if you have two keys of equal precedence?

My specific example

I'm attempting to write a theme that works well for the Nix language. My goal is for all strings to be given the same color, even those in an attribute's key. So, in this example:

{
  foo = "bar";
  one."two" = 3;
}

I want to ensure "bar" and "two" are both highlighted the same color. Setting string.fg to some color accomplishes this.
However, what if I want to highlight non-string keys? In this case, foo and bar should receive a certain styling, while the"two" in quotes should not receive this color. I can change the color of these keys by setting variable.fg.

But, now we reach the problem. variable.fg seems to be overriding string.fg, meaning it's setting all variables, even those that should be highlighted as a string. I'm guessing this is because the test for "longest matching theme key" just matches the character length of the key, and variable is longer than string. There doesn't exist a longer string scope that will touch Nix strings, so I'm stuck.

How to fix this

Of course, in my specific case, adding a longer key for strings would fix this. In the documentation on strings, it mentions a TODO list: TODO: string.quoted.{single, double}, string.raw/.unquoted)?. Adding string.quoted would be longer than variable, so it'd override it. However, this is only a fix for my specific scenario. I think a better fix would be the ability to specify precedence, so you didn't have to rely on the length of the key.

A relatively simple implementation of this to implement would be a boolean key alongside fg, bg,underline, and modifiers, where you could specify whether a key should be set above other keys, even those of the same length. If this key was ever set to true, it would be weighted to the top when choosing which style is applied, even over keys of a longer length. If multiple different keys had this value applied, it would then revert to choosing the longest one.

As an alternative, slightly more in-depth approach, I think using a numerical value might work better than a simple boolean. The number would specify how much precedence that key would receive, with a higher number corresponding to a higher precedence. This would work better with multiple keys specifying a high precedence.

I'm not that picky about the actual method for specifying precedence - I just think there should be some way to do it. Simply choosing precedence based on string length works in a hypothetical world where you can always choose a longer key, but if you've already gone as deep as you can, I don't see a clear workaround other than adding manual precedence.

[the-mikedavis]

That line in the docs is about which style is used from the theme for a scope set by a language's highlight queries or looked up for the UI. For another example, rulers are highlighted with "ui.virtual.ruler". If a theme defines that key it is used and there's a fallback behavior so that if a theme doesn't set "ui.virtual.ruler" but sets "ui.virtual" instead, that will be used as a fallback. And if a theme only sets "ui" that will be used if neither "ui.virtual.ruler" or "ui.virtual" are defined. The key with the most number of components (rather than string length) that matches the requested key ("ui.virtual.ruler" in this example) will be used. That fallback behavior doesn't apply to keys that aren't nested: "variable" and "string" will never compete with one another.

Instead what you're looking for is how these keys are specified by a language's highlight queries. In runtime/queries/nix/highlights.scm bindings are highlighted with:

(binding
  attrpath: (attrpath attr: (identifier)) @variable.other.member)

This only matches unquoted tokens ((identifier) rather than (string_expression)). If you wanted to highlight attrs that are quoted you could update the query to match either:

(binding
  attrpath: (attrpath attr: [(identifier) (string_expression)] @variable.other.member))

And you would need to move this pattern:

[
  (string_expression)
  (indented_string_expression)
] @string

below the binding one so it has a lower precedence.