Add .vs (folders automatically generated by Visual Studio) to .gitignore

[tats-u]

Based on https://github.com/github/gitignore/blob/main/VisualStudio.gitignore (it contains extra files for C#/F#/VB.NET)

This change will ignore files generated when the folder is opened by Visual Studio:

Visual Studio supports the test execution:

[tats-u]

Just reworded the commit

[jgm]

Would this be better handled by adding something to your user gitignore?

https://stackoverflow.com/questions/5724455/can-i-make-a-user-specific-gitignore-file

After all, it will get to be a hassle if we need to keep modifying this file every time someone with a different editor or IDE works on the project...

[tats-u]

I'm afraid Visual Studio Community is too major free option for OSS development to tell every users to do so.
It's one of the best C/C++ development environment for Windows users.
I added "major" to make users of minor IDEs/editors hesitate to create PRs for theirs.

I know CLion as one of excellent C/C++ IDEs but it's not free.

.vs folder will be created once you open the folder with Visual Studio.

[tats-u]

Removed the extra entry.

[nwellnhof]

The .gitignore file should only be relevant for people working on the cmark code and I think it's safe to say that the vast majority won't be using Windows. This debate typically starts with a request to add vim .swp files to .gitignore but all of this really belongs into the user's global ignore file.

[jgm]

Here's the process:

# Create $HOME/.gitignore
# Add whatever you like to it
git config --global core.excludesfile $HOME/.gitignore

[tats-u]

React, Gecko (Firefox), and Docker Compose have done for .swp: https://github.com/facebook/react/blob/76e07071a11cd6e4796ad846bc835a18c8f49647/.gitignore / https://github.com/mozilla/gecko-dev/blob/597ad02dc79ede5fde68cafab874bf000e47f50b/.gitignore / https://github.com/docker/compose/blob/706164accd1eb8f12782dc12bb84c64aea742807/.gitignore
(Note: they're not majority but still large projects)
Cmark starts in 2014 but The CMake support by Visual Studio starts in 2017.
Makefile is added to cmark prior to CMakeLists.txt and they show cmark has been grown mainly by Unix developers.
However, Visual Studio is like Xcode for macOS users. If you don't like or choose Apple's device, you will install Windows in most cases. (unless you won't run proprietary apps like Office and games)
It has been just 7 years (2 versions) since Visual Studio started CMake support. We'll have more and more chance to get contribution by Windows users in the future.
100% of Visual Studio users will want this .gitignore change.
Unlike .swp file, .vs will be created once you just open the workspace folder just for build and analysis. It remains even after closing Visual Studio. The worktree will get dirty. It's pitfall.

I've already added .vs and out in .git/info/exclude. I'm not in hurry.

[tats-u]

I think .swp has already been supported because the line *.sw? exists in .gitignore.

cmark/.gitignore

Line 28 in 2734f21

*.sw?

The following line seems to be for Vim and Emacs users:

cmark/.gitignore

Line 26 in 2734f21

*~

[jgm]

Philosophically I agree with @nwellnhof that it would be best for things like .swp and .vs to go in the user's local gitignore, since they concern the user's tools, and not files that are created by the project itself. Also, as noted above, there's a danger of proliferation; if everyone wants their pet editor/ide's temporary or config files in .gitignore, then we need to keep updating the project for reasons unrelated to the actual code. (.sw? was added before I understood about local gitignore.)

However, I don't feel very strongly about this, since adding stuff to .gitignore isn't harmful in itself.

@nwellnhof if you do feel strongly then I'll close this. If you feel inclined to compromise on this, maybe we could merge it.

[tats-u]

I have just noticed .sw? doesn't include .*.swp.
Visual Studio is not used except for C/C++/C#/VB unlike Vim due to its long startup time and poor support for non-BOM UTF-8.

[nwellnhof]

@nwellnhof if you do feel strongly then I'll close this.

I don't have a strong opinion.