search

zyedidia / micro

A modern and intuitive terminal-based text editor
https://micro-editor.github.io
MIT License
24.93k stars 1.17k forks source link

Improve micro's file format hightlight #3199

Open dustdfg opened 6 months ago

dustdfg commented 6 months ago

Honestly I don't think current approach is flexible

dmaluka commented 6 months ago

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 commented 6 months ago

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

dmaluka commented 6 months ago

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

I can't see why?

dustdfg commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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