-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Error detecting file type by signature
#3201
Comments
With #2819 it was changed in that way that it considers the It can be discussed to try this guess as well in the moment no file type check hit at all, but this again could lead to false positives in the moment the So from that point there is no guarantee to hit exactly, it would be a guess and it could be wrong (with a chance for new issues). |
In my opinion, the fields within the But in view of the behavior of the |
But wasn't the same question legit for the old json
Currently me too, but this doesn't mean that they don't exist. I "broke" some expected default handling in the past. The signature check can help as fallback and heavily relies on sufficient rules.
So you'd recommend to consider to provide this as a fallback method and remove insufficient signatures, right? |
I don't think so, all files that start with The point is that the header has been changed as if it were for an equivalent, which is not true. I think the right thing to do in this case would be to remove it from the file, but that's not my decision.
No, actually the I was just thinking that the signature was the same as the header, I hadn't correctly understood the function of |
But the problem still persists but it will only happen if the file name matches more than one file type, the problem would be the signature patterns, they must be fixed, improved and added so that false positives can be corrected. The |
Maybe user can be asked about filetype if it was deduced from patterns or can be added one more option to control if patterns are used at all |
Placing an option that activates or deactivates the use of Maybe warn that * `detectsignature`: If it is `true`, the `signature` field of the syntax files
will be used to try to find the `filetype` when it is `unknown` or when
more than one `filetype` is found (this function may end up generating false positives, if this happens please report the bug so we can improve its functionality).
default value: `false` But I still believe that |
I'm open for that. We just need to keep in mind, that this will have downsides. Just one example: So proper highlighting should be produced with explicit file extensions or whole file names in the syntax definition. Everything else is some (better) guessing, especially in cases with more or less "wildcard" signatures. |
Ok. What vim does? You said in one of the PR's vim uses similar approach so do they have the issue? |
So the file name "Pipfile.lock" is explicit tracked to be of a json file type. 😉 For *.h files for example |
From what I understand, the I believe that the solution for the Pipfile.lock file is to update the The question is, what does the
If I put the What is this field for? How do I find this information without having to review PR's and issues? |
No, as described in #3183 the
See above.
It will iterate over the amount of
As written, it's currently used to define the chosen one of multiple
In case the pattern is insufficient or
As of now, I agree that it most probably was a fault to keep them available (with the same pattern as before with
Well, what shall I say/write? As already often said: Help is appreciated with support to prepare the proper doc update. 😉 |
I've read the discussion and I come to a conclusion that we should admit that replacing "headers" with "signatures" was a hasty decision. It is not just a matter of a proper doc update, it is a matter of breakage of useful functionality. If we have a file named
with v2.0.13 it is recognized and highlighted as a shell script. With the newest master it is not. To me, this is a regression, and a rather serious one. The majority of micro's syntax files have no So I think we should restore the When it comes to false positives caused by |
Although perhaps we should make |
Off topic sorry... It is a good place for a tuned and lightweight AI similar to googles magika which weights 1MB and it would be really perfect for such a problem. It is even open source |
Ok, then we keep it short and
Yep, Last but not least the doc of |
Description of the problem or steps to reproduce
When opening the Pipfile.lock file it looks like this:
{ "_meta": {} }
The type shown is
unknown
, but as specified in thesignature
of the file:micro/runtime/syntax/json.yaml
Lines 1 to 5 in 4338790
I did the same test with the file named
index
with the following content:<!DOCTYPE html5>
From what I understand, both should be of type
json
andhtml5
given thesignature
of html5:micro/runtime/syntax/html5.yaml
Lines 1 to 5 in 4338790
I didn't get to test the other types of files that can be defined with
signature
but as both files should match with the regex I believe the same thing must be happening.This does not happen in version 2.0.13.
The file detection was changed with #2819.
Specifications
Commit hash: b518bda
OS: Ubuntu 22.04.3 LTS
Terminal: terminator
The text was updated successfully, but these errors were encountered: