Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve micro's file format hightlight #3199

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

dustdfg
Copy link
Contributor

@dustdfg dustdfg commented Mar 20, 2024

Honestly I don't think current approach is flexible

Signed-off-by: Yevhen Babiichuk (DustDFG) <[email protected]>
@dmaluka
Copy link
Collaborator

dmaluka commented Mar 22, 2024

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
Copy link
Contributor Author

dustdfg commented Mar 22, 2024

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

@dmaluka
Copy link
Collaborator

dmaluka commented Mar 22, 2024

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

I can't see why?

@dustdfg
Copy link
Contributor Author

dustdfg commented Mar 22, 2024

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
Copy link
Contributor Author

dustdfg commented Mar 22, 2024

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
Copy link
Collaborator

dmaluka commented Mar 22, 2024

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
Copy link
Collaborator

dmaluka commented Mar 22, 2024

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
Copy link
Collaborator

dmaluka commented Mar 22, 2024

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
Copy link
Contributor Author

dustdfg commented Mar 22, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants