syntax: requirements: add syntax highlight code for requirements.txt files

[taconi]

Adding support for syntax highlighting of requirements.txt files

[dustdfg]

I think it is too broad file name requirements.txt so it can be used by any program and can have different format for different program. Autodetecting format by this name is wrong idea in my opinion. Pipfile is unique file name but not this

[dustdfg]

It think Pipfile.lock also one candidate for auto-detect

[taconi]

The requirements.txt file is still widely used, as are requirements-dev.txt files, or even requirements/dev.txt. requirements.in is the file that pip-tools recommends for the user to place abstract dependencies like httpx so he can create concrete dependencies like httpx==0.27.0 and httpx dependencies. Despite the python community adopting pyproject.toml as the file that will store dependencies, many people and many large projects like flask have not yet adopted this standard.

[taconi]

It think Pipfile.lock also one candidate for auto-detect

The file falls into the header match of json files in version 2.0.13 of the micro, https://github.com/zyedidia/micro/blob/68d88b571de6dca9fb8f03e2a3caafa2287c38d4/runtime/syntax/json.yaml#L3-L5

However, in the version of the last master commit this does not happen for me, @dustdfg could you confirm this? I don't know if it would be worth opening an issue.

[dustdfg]

However, in the version of the last master commit this does not happen for me, @dustdfg could you confirm this? I don't know if it would be worth opening an issue.

Maybe something is wrong on my side but it doesn't work on my side and one more thing. Instead of header there is signature in master...

[taconi]

Maybe something is wrong on my side but it doesn't work on my side and one more thing. Instead of header there is signature in master...

Even with a header, detection is not done, I will look at other cases later to confirm and open an issue about it if someone doesn't do it first.

But regarding the PR, I believe that adding syntaxhighlt to the python package dependency files would be very useful. Maybe one thing or another was left without highlt but once it already exists it can be improved.

[JoeKar]

It think Pipfile.lock also one candidate for auto-detect

The file falls into the header match of json files in version 2.0.13 of the micro,

https://github.com/zyedidia/micro/blob/68d88b571de6dca9fb8f03e2a3caafa2287c38d4/runtime/syntax/json.yaml#L3-L5

However, in the version of the last master commit this does not happen for me, @dustdfg could you confirm this? I don't know if it would be worth opening an issue.

The file detection was changed with #2819.

[dustdfg]

The file detection was changed with #2819.

Ok but... It doesn't work at least for json. It isn't detected as json

{
    "_meta": {
        "hash": {
            "sha256": "d09f41c21ecfb3b019ace66b61ea1174f99e8b0da0d39e70a5c1cf2363d8b88d"
        },
        "pipfile-spec": 6,
        "requires": {},
        "sources": [
            {
                "name": "pypi",
                "url": "https://pypi.org/simple",
                "verify_ssl": true
            }
        ]
    }
}

[taconi]

@dustdfg The changes to file type detection were:

• remove the header field to false positive values ​​like #2041.
• the signature field was added to try to resolve the case where the file name matches more than one type using the filename field. if there is more than one they will be ignored, all files that have the signature will be checked and the first match of this field will be used as the file type, if no syntax file that has the signature matches the file type will be unknown.
• the detectlimit option was added, with it you can limit how many lines can be used from the buffer to try to match the signature.

Now the case in which the file name Pipfile.lock that begins the text { in the first line will be considered as json if you have another file with the field filename that matches .json, that is, if Exits a syntax file like ~/.config/micro/syntax/foo.yaml or ~/.config/micro/plug/batata/syntax/foo.yaml or runtime/syntax/foo.yaml:

filetype: "foo"

detect:
  filename: "\\.lock$"

rules:
- include: "toml"

and a syntax file like ~/.config/micro/syntax/bar.yaml or ~/.config/micro/plug/bar/syntax/assada.yaml or runtime/syntax/bar.yaml:

filetype: "bar"

detect:
  filename: "\\.lock$"

rules:
- include: "python"

In this case the file has two types, foo and bar and then the signature field will be used to try to define the file type and then when you open the Pipfile.lock file the file type should be json , right @JoeKar ?

[JoeKar]

In this case the file has two types, foo and bar and then the signature field will be used to try to define the file type and then when you open the Pipfile.lock file the file type should be json , right @JoeKar ?

Well, I don't know how you came to the conclusion that it will be json. It will be foo (toml rules/highlighting) or bar (python rules/highlighting), but you didn't define a signature for one of both so the first one will win, which in your case would be bar...we've to remember the alphabetical order. At the end your Pipfile.lock will be of file type bar and highlighted with python rules.

[taconi]

Well, I don't know how you came to the conclusion that it will be json

True, the file type would be bar and not foo because the letter b comes before the letter f (couldn't this behavior generate bugs? Like foo which can only be defined as a file type on the day that it has a signature and will only be actually defined when it matches the file signature).

Pipfile.lock will only be able to match the signature on the day that the json files match the filename as Pipfile\\.lock$ and there are other matches for filename and these other matches are not have signature or if they have filetype ordered after json, like kson.

I confess that I find the behavior of signature somewhat complex (I don't even know if I understand it correctly) and that it came to try to hide the old bug in the header field from false positives.

Perhaps documentation of the known scenarios in which signature works and doesn't work could help clarify.

[...] signature regex that will check a certain amount of lines of a file to find specific marks

This is wrong, signature will only be used in some scenarios, but which ones are not mentioned.

[JoeKar]

This is wrong, signature will only be used in some scenarios, but which ones are not mentioned.

Here I do not fully agree. Definitely the documentation can be improved, check...nobody is perfect. The statement isn't wrong, the mechanism does exactly that. In fact it's just half of the truth, but this doesn't declare it to be wrong. Let us continue in #3201.

Here we can only define proper filename checks to be precise enough.