The idea is to provide a boilerplate for quickly creating new Nim projects with all the basic settings in place for any cross-platform project. This should be particularly helpful for Nim newbies (like me) who might not know all the Nim related file extensions that could show up in a project.
For example, I've also added some GitHub Linguist attributes to indicate that *.nimf files should be considered Nim files in project statistic and syntax highlighting (the new SFF extension has not yet been added to Linguist).
The template is far for complete, just an initial proposal.
From an exchange with @Araq, I learned that the best practice is to always set Git to normalize EOLs to LF, even under Windows OS:
Many editors packages for Nim use native EOL for Nim sources, and I haven't find any references in the official documentation regarding best practices for these type of settings in commonly shared projects. So I was hoping that this repository might be useful in this respect — it's Wiki is open to editing and can be used to provide guidelines.
My original idea was to create the repository and then transfer ownership to the Nim-Lang GitHub organization, but then I realized you can only transfer repositories to organizations where you have enough privileges to create repositories yourself (I though I could simply request transferal, and the Nim-Lang org could accept or decline).
Repository templates are a new GitHub features (June 2019) which I think is quite cool. Beside saving time when creating new repositories, the presets of a well designed template can also cover a variety of work scenarios, different compiler backends, etc.
From an exchange with @Araq, I learned that the best practice is to always set Git to normalize EOLs to LF, even under Windows OS:
Hey, wait a second, I didn't say that! I said git shouldn't touch the newlines.
Hi @Araq, sorry for the late reply,
Hey, wait a second, I didn't say that! I said git shouldn't touch the newlines.
The reason I said "I've learned that..." is because of tools like c2nim output Nim sources with LF even on Windows (that was the original question on the repository Issue). Since you confirmed to me that using LF as EOL in c2nim is the expected behavior, then it makes sense to set Git to use LF on all Nim sources — otherwise one would have to create separate rules for manually coded Nim sources and sources generated by Nim tools.
The EOL problem only affects Windows users, and unless the repository .giattributes file is properly set the risk is that Windows users might commit to the repository index files with CRLF EOL — which indeed would be a problem for Linux and macOS users. Unless explicitly set to LF, Git would normalize text files to the native EOL, which under Windows is CRLF.
Unfortunately, the Nim documentation doesn't mention best practice regarding source files and EOL usage, so the various Nim editors extensions use different defaults (e.g. Sublime Text uses native EOL) — the whole idea in creating this template was to provide some ready to use presets, so any advise on how to improve it are indeed welcome.
Quoting your reply to the original Issue:
The EOL convention is LF-everywhere indeed. And git should always be configured to "don't touch the newlines" anyway, how else can you write tests that contain CR-LF for Linux?
The above can only be achieved by telling Git to normalize Nim sources to LF — if you use native EOLs then Git will indeed need to touch newlines under Windows and convert them at checkout from LF to CRLF. But the main issue is that sources auto-generated by Nim tools use LF, so it makes more sense to also adopt LF in the editor to avoid a double standard. Does it make sense?