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

Syntax highlighting is bad? #3167

Closed
og900aero opened this issue Mar 8, 2024 · 4 comments
Closed

Syntax highlighting is bad? #3167

og900aero opened this issue Mar 8, 2024 · 4 comments

Comments

@og900aero
Copy link

I use Debian 12 stable with alacritty. I try micro editor compared with nano, and I find that micro is able to recognize which syntax highlighting to use for much fewer files, than nano. It does not recognize such popular config files as fail2ban, interfaces, nftables, etc. Meanwhile, nano minimum colors the comments, but also the [] parts indicating groups in the case of fail2ban.
Will Micro not be developed from this point of view?

@JoeKar
Copy link
Collaborator

JoeKar commented Mar 8, 2024

The syntax highlighting isn't bad, but has room for optimization/extension.
I already suggested with #2933 an PR to include an default scheme, as nano does for unknown file types. But this will be quite limited and does, as of now, not highlight any braces.
What you expect is the highlighting of the ini file type, which I apply for /etc/* too ~/.config/micro/settings.json:

{
    "/etc/*": {
        "filetype": "ini"
    },
    [...]
}

@og900aero
Copy link
Author

og900aero commented Mar 9, 2024

"/etc/*": {
"filetype": "ini"
},

Thx, working. The only problem with this is that inside the at etc folder it will also show what would otherwise be a normal syntax highlightning.
A default would certainly be nice. According to this, the developer is not willing to do this?

@JoeKar
Copy link
Collaborator

JoeKar commented Mar 9, 2024

According to this, the developer is not willing to do this?

We're on a good way to get more extended rights to support the project owner. 😉

@og900aero
Copy link
Author

According to this, the developer is not willing to do this?

We're on a good way to get more extended rights to support the project owner. 😉

Good to hear that! Because I would not like to go back to nano :)

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

No branches or pull requests

2 participants