consistent pattern colors for fields in repeated elements?

[rumblerosesxx]

Really liking this editor, the pattern matching is really nice and has helped me visualize the binary format I'm reverse engineering. One thing I'm struggling with is getting repeated fields colored consistently. It seems by default if you have a repeated struct each new element of that struct gets random field colors and the only way I've been able to force them to be consistent is to assign colors manually to each field. Is there an attribute I'm missing that would force this behavior on the entire list?

[paxcut]

I don't think such attribute exists because each pattern definition is independent of the others so it is not clear how the colors of one pattern could be used to color another pattern. The language does allow you to define a redVariable type which can be of any underlying type and will always be colored red. The following code was tested, works as expected and shows how that is done.

using redVariable<T> = T [[color("0x00FF0000")]];// green 0000FF00 blue 000000FF

struct T {
    redVariable<u8> a; // always red

};

T t@0;

Note that the example can easily be extended to arbitrary colors. One possible way:

using coloredVariable<T, auto colorStr> = T [[color(colorStr)]];

#define red   "0x00FF0000"
#define green "0x0000FF00"
#define blue  "0x000000FF"


import std.io;

struct Test {
    coloredVariable<u8,red>   a;
    coloredVariable<u8,green> b;
    coloredVariable<u8,blue>  c;

};

Test t@0;

This also can be used to color entire patterns using one chosen color

[rumblerosesxx]

I understand the mechanism for what I'm describing is not currently implemented but for nested fields it seems caching the colors previously used and doing a lookup to keep them consistent when matching on the same types in the future would create for better visual parsability, and naively would not be super complicated to implement. Though I haven't looked at the source so I could certainly be wrong here. But I might even argue it would be a better default than the current approach of seemingly random colors and not require additional attributes.

[WerWolv]

The way it works in code currently is that we have a list of colors that can be used and each pattern that gets created just takes the current color and advances the index into that list forward by one, cycling back to the front if it hits the end.

The thing you're describing happens if you apply the [[static]] attribute to your type. Then only the first entry in an array of these types gets colored like this and all other entries are merely copies of it.
That of course doesn't work for types whose layout is not static but in that case, coloring the fields consistently would not really be possible either way.

[rumblerosesxx]

Aha, [[static]] looks like it almost works. But it only handles simple structs made of primitive types that don't themselves reference any other data. That's good enough for me for now, thanks! But please consider the approach I mentioned of caching the color selection for a particular type and using it if previously selected to keep them consistent across different manifestation of the same struct in multiple places.