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

Bug: no syntax highlight in flake.nix with flake.lock #3054

Closed
SamueleFacenda opened this issue Nov 29, 2023 · 2 comments
Closed

Bug: no syntax highlight in flake.nix with flake.lock #3054

SamueleFacenda opened this issue Nov 29, 2023 · 2 comments

Comments

@SamueleFacenda
Copy link

SamueleFacenda commented Nov 29, 2023

I'm facing a strange bug with syntax highlighting, it works well (not awesome but well) with nix files, but it fallbacks to the default one (the one with only strings, true/false and int) in every flake.nix file (a standard entry point for nix).
I did a bit of research and I found out that this only happen when there is a flake.lock file in the same directory (it's always the case, with nix).
After removing the flake.lock file, in order to have syntax highlight back in the flake.nix file, I have to cut out the content of flake.nix, close micro, reopen micro and paste everithing back.

Commit hash: v2.0.12
OS: NixOS
Terminal: kitty

@JoeKar
Copy link
Collaborator

JoeKar commented Nov 29, 2023

The problem isn't the flake.lock file, but the first line/character {. Am I right?
This start of the file leads to a false positive interpretation as json file type, caused by this line json.yaml#L5.

It will be fixed with #2819 too.

@SamueleFacenda
Copy link
Author

Yes, you are right. The filetype caching confused me. That was my first idea.

dmaluka added a commit to dmaluka/micro that referenced this issue Mar 24, 2024
Replacing header patterns with signature patterns was a mistake, since
both are quite different from each other, and both have their uses. In
fact, this caused a serious regression: for such files as shell scripts
without *.sh extension but with #!/bin/sh inside, filetype detection
does not work at all anymore.

Since both header and signature patterns are useful, reintroduce support
for header patterns while keeping support for signature patterns as well
and make both work nicely together.

Also, unlike in the old implementation (before signatures were
introduced), ensure that filename matches take precedence over header
matches, i.e. if there is at least one filename match found, all header
matches are ignored. This makes the behavior more deterministic and
prevents previously observed issues like zyedidia#2894 and zyedidia#3054: wrongly
detected filetypes caused by some overly general header patterns.

Precisely, the new behavior is:

1. if there is at least one filename match, use filename matches only
2. if there are no filename matches, use header matches
3. in both cases, try to use signatures to find the best match among
multiple filename or header matches
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