Improve micro's file format hightlight

[dustdfg]

Honestly I don't think current approach is flexible

[dmaluka]

Also at least the selection colorgroup is still missing.

BTW I've updated the colorgroups documentation in PR #3203.

Yeah, current approach in micro.yaml is not quite scalable. Moreover, micro actually allows extending basic syntax colorgroups (type, identifier etc) with arbitrary subgroups (type.keyword, identifier.foo.bar etc), and that is documented. So we should probably highlight any of those abritrary subgroups, not just a fixed limited set of subgroups. For example, instead of:

    - identifier: "\\b(identifier(\\.(class|macro|var))?)\\b"

just:

    - identifier: "\\b(identifier(\\.\\S*)?)\\b"

[dustdfg]

I agree with - identifier: "\\b(identifier(\\.\\S*)?)\\b" moreover I would say we need to highlight something like \\b(i\\S(\\.\\S*)?)\\b

[dmaluka]

moreover I would say we need to highlight something like \\b(i\\S(\\.\\S*)?)\\b

I can't see why?

[dustdfg]

Wouldn't user want to create custom colors? You can think that all the possible situations are covered and won't new top-level names exist but then someone just wants to create git highlight and then new colorgroup is added. I mean just to highlight any valid by syntax colorgroup

[dustdfg]

One more rock in the side of the color groups. They aren't coherent in my opinion. diff-added, diff-modified 3 different top level things and not diff.added...

As like for error and tab-error. Why not error.tab?

[dmaluka]

Wouldn't user want to create custom colors? You can think that all the possible situations are covered and won't new top-level names exist but then someone just wants to create git highlight and then new colorgroup is added. I mean just to highlight any valid by syntax colorgroup

Well, perhaps... OTOH then completely unsupported top-level names (e.g. if the user makes a typo) would be highlighted as well.

[dmaluka]

One more rock in the side of the color groups. They aren't coherent in my opinion. diff-added, diff-modified 3 different top level things and not diff.added...

Perhaps, but changing them now would mean at least breaking compatibility.

As like for error and tab-error. Why not error.tab?

Hmm, is error used at all?

[dmaluka]

Speaking of specifically diff-added, diff-modified etc: making them subgroups of diff would make sense if there was a use case for highlighting them all with the same color (so then specifying just the diff color would be enough). But I doubt there are users that would want that. :)

[dustdfg]

Hmm, is error used at all?

Looks like no. Grep said about gutter-error, tab-error, error-message but no plain error in go files