syntax: pipfile: add syntax highlight code for Pipfile files

[taconi]

Adding Pipfile file syntax support.

[dmaluka]

Any reasons why not just add Pipfile to the filename pattern in runtime/syntax/toml.yaml?

[dustdfg]

How user will find it?

[dmaluka]

What do you mean? The user will see ft:toml in the status bar, thus will know that the toml highlighting is used.

[dustdfg]

Looks like a very good reason. At the same time I have a question. Won't the files get too overwhelmed with detection patterns?

[taconi]

Any reasons why not just add Pipfile to the filename pattern in runtime/syntax/toml.yaml?

None in particular, I just got my personal ~/.config/micro/syntax/pipfile.yaml.
If it's better to put it in runtime/syntax/toml.yaml, great. Whatever is decided I will implement for the Pipfile.lock files too.

[dustdfg]

If you put separate file you will get one more file but it will have reasonable name so it could be easily found which doesn't have much sense because you won't need to edit it if you just import settings. You will also get ft:custom_name

If you include the filename to the existing file you will end up with too many custom names for config files of different languages/projects in one string. You will also get ft:real_name

[dustdfg]

+ #3201 (comment)

In what cases could there be an error?

In case the pattern is insufficient or filename will be changed without considering signature once again.
That's definitely something to keep in mind when we decide to add more filename patterns into already existing definitions and don't create new dedicated definitions.

[dmaluka]

If you put separate file you will get one more file but it will have reasonable name so it could be easily found which doesn't have much sense because you won't need to edit it if you just import settings. You will also get ft:custom_name

If you include the filename to the existing file you will end up with too many custom names for config files of different languages/projects in one string. You will also get ft:real_name

Yep, these points are obvious to me too, and they mean to me that both @taconi and non-@taconi approaches are equally good/bad. So I was looking for more arguments to see which one is better/worse.

Actually now I've recalled an argument against @taconi approach: we already follow the non-@taconi approach, i.e. for ruby:

    filename: "\\.(rb|rake|gemspec)$|^(.*[\\/])?(Gemfile|config.ru|Rakefile|Capfile|Vagrantfile|Guardfile|Appfile|Fastfile|Pluginfile|Podfile|\\.?[Bb]rewfile)$"

or shell:

    filename: "(\\.(sh|bash|ash|ebuild)$|(\\.bash(rc|_aliases|_functions|_profile)|\\.?profile|Pkgfile|pkgmk\\.conf|rc\\.conf|PKGBUILD|APKBUILD)$|bash-fc\\.)"

If we now introduce using the @taconi way as well, it will cause confusion in deciding which way to follow in the future. And if we instead convert all those Rakefile, Capfile and so on to the @taconi way, it will surely overcrowd the list of "supported file types" too much.

• #3201 (comment)

In what cases could there be an error?

In case the pattern is insufficient or filename will be changed without considering signature once again.
That's definitely something to keep in mind when we decide to add more filename patterns into already existing definitions and don't create new dedicated definitions.

At first, this (i.e. avoiding non-determinism caused by filename clashes) sounded like a good argument to me. But then I realized that would not really avoid non-determinism. E.g. if we have a foofile.yaml syntax file with filename: "file$", i.e. matching Pipfile, Makefile etc, and it has no sufficient signature, then we will have a clash regardless of whether we add Pipfile to toml.yaml or add a separate pipfile.yaml for it, right?

[taconi]

if we have a foofile.yaml syntax file with filename: "file$", i.e. matching Pipfile, Makefile etc, and it has no sufficient signature, then we will have a clash regardless of whether we add Pipfile to toml.yaml or add a separate pipfile.yaml for it, right?

I believe so, but leaving it separate we can use the signature field to try to get around this error.
Something like this might solve it:

filetype: Pipfile

detect:
  filename: "Pipfile$"
  signature: "\\[\\[source]]"

rules:
- include: toml

The default today is to put a | in the regex and add another pattern, but for new syntax files I believe it can be looked at carefully to see if there is a need and what errors can be generated from this before moving on to a separate file, like the one in filename: "file$".
More detailed documentation with success and error examples about color schemes and files could help people creating syntax files.

I believe that in this case it should be a separate file with a good signature, I don't know if the best would be "\\[\\[source]]", that's another point, but with regards to adding the Pipfile$ to the filename of the toml or create a separate file, I think the latter would be the most appropriate as this way the signature can be added.

[dmaluka]

Just a second... As we are talking specifically about the Pipfile case, which problem would we solve by adding signature for it? AFAICT signature is just for resolving ambiguities between multiple syntax files matching the same file by their filename patterns, e.g. for C/C++/Objective-C header files (*.h). Do we really have such an ambiguity problem with Pipfile? I.e. do we have (or will likely have in the future) any other syntax files that match Pipefile$?

The filename: "file$" example I came up with is just an artificial example, I doubt anyone sober would use it in real life.