Change file extension

[enderger]

Is your feature request related to a problem? Please describe.
Currently, the Nickel language uses the .ncl file extension. However, as shown by the GitHub statistics, this name is already in use! This prevents filetype integration from being viable.

Describe the solution you'd like
I propose that the Nickel project adopts the .nkl extension, which appears unused in my limited searching.

Describe alternatives you've considered
We could also use .nickel (which is a bit verbose), .nikl (which is the best alternative IMO), or do nothing (though this will make things harder long-term and be harder to fix later).

Additional context
The NCL project: https://www.ncl.ucar.edu/

[gytis-ivaskevicius]

Here are my two cents:

1. Only a single extension should be supported - useful in case of searching GitHub for nickel files
2. I prefer .nkl, looks nicer

[enderger]

Here are my two cents:

1. Only a single extension should be supported - useful in case of searching GitHub for nickel files
2. I prefer .nkl, looks nicer

I agree with point 1, though my reasoning behind the alternative .nikl extension being viable is that it can easily be pronounced "nickel", though it is a bit unsightly (hence why I proposed .nkl as the main candidate).

[mboes]

I don't think clashing file extensions are a problem per say. Case in point: there are currently four separate entries registered in Linguist's language.yaml for the .ncl extension. Nickel would just add a fifth. Another example would be both Perl and Prolog using the .pl extension. Arguably, the intersection of NACL users and Nickel users is even smaller than the intersection of Perl and Prolog users. GitHub does not use file extensions exclusively as the way to determine which language appears in a given file. In fact it's not even the first strategy. See here. However, if we do stick to .ncl then we indeed should make a PR against github/linguist to make detection of Nickel more accurate.

.ncl can stand for Nickel as well as for Nickel Configuration Language or Nix Configuration Language. The "cl" part is quite nice to have in the name.

[enderger]

I don't think clashing file extensions are a problem per say. Case in point: there are currently four separate entries registered in Linguist's language.yaml for the .ncl extension. Nickel would just add a fifth. Another example would be both Perl and Prolog using the .pl extension. Arguably, the intersection of NACL users and Nickel users is even smaller than the intersection of Perl and Prolog users. GitHub does not use file extensions exclusively as the way to determine which language appears in a given file. In fact it's not even the first strategy. See here. However, if we do stick to .ncl then we indeed should make a PR against github/linguist to make detection of Nickel more accurate.

.ncl can stand for Nickel as well as for Nickel Configuration Language or Nix Configuration Language. The "cl" part is quite nice to have in the name.

While there may be several languages already using the name, a 5-way conflict is a bit much IMO. Also, more naive tools may not fare as well as GitHub in extension support, and even then false positives/negatives could be likely. Finally, I personally think that .nkl or .nikl more clearly reference the "nickel" language than .ncl (which could be confusing, especially when searching for the file type by extension).

[gytis-ivaskevicius]

I don't think clashing file extensions are a problem per say...

I think it is a problem due to tooling integration and to cover simple use case like this:
https://github.com/search?q=something+extension%3Ancl (I'd expect to see only Nickel configuration files instead of these results)

[andir]

Why not just use nickel? It is just three more characters.

[grahamc]

.ncl can stand for Nickel as well as for Nickel Configuration Language or Nix Configuration Language. The "cl" part is quite nice to have in the name.

I come to the opposite conclusion, that having something so ambiguous is quite unfortunate.

[gkaracha]

I have no horse in this race but I totally agree with @andir here. For what it's worth, there are popular file extensions out there that are 5 (e.g., .class, or .pages) or even 7 (e.g., .torrent) characters long.

[frontsideair]

A bit old thread, but I just saw this project and thought “it would be fun if the extension was .5c” For those unfamiliar (like me) a nickel is worth 5 cents. Also another fun extension would be .ni as the chemical symbol, but I’m sure it’s already taken.

There are other projects which do this, like Squirrel and .nut extension.

Just my 5 cents. :)

[yannham]

There's also .nicl, in the same theme of chemistry.

[piegamesde]

I suggest using .ni as the extension as well, but unironically.

[keithy]

I think it is useful to anticiplate more than one extension, sometime you have duel code hierarchies sharing the same repository. Such as code and adjacent tests. If you start with only one, without thinking ahead a little, then all the tools, only support that one. As a trivial example. .nix and .test.nix could have been .nix and .nixt

I like the .5c idea, and .10c for plugins/libraries (i.e config vs code) and miraculously both of these don't appear to be taken. Why dont we just appropriate the whole .XXc namespace.

I have looked at 1c,2c,5c,10c,25c, and the irresistable 50c, they all look available to me. (github search) (.3c is used a little)

[Xophmeister]

My vote is also for .ni:

• Relevant chemical symbol 👍
• One fewer character to type 👍
• No k, which I'm not a fan of aesthetically 👍