@tonyroberts any idea whyAppveyor isn't running anymore on thepull request? Noticed it yesterday. I verified the build against myAppveyor account and its passing, so itTravis-ci

As I side note, i don't fully agree with VS's choice of style, but I'd rather see consistent formatting.

I'm fine with cleaning up whitespace etc, but I think reorganising the file structure should be done in a different PR. In particular, I don't think moving very old and out dated documentation into the root folder is a good idea. I think it would be better if it was updated and then moved - rather than delay these whitespace changes until that's done, dropping them from this PR seems sensible.

Also the wording of commitf72c7e0 comes across as a bit derogatory towards mono (even if that wasn't the intention) and could give someone casually looking through the commit history the impression that mono is less supported than the microsoft runtime, which is not the case.

@vmuriart hmm not sure what happened to the appveyor CI - looks like there was some problem with the github settings, which is odd as I'm pretty sure I didn't change them! Anyway, hopefully it will be working again now..

@tonyroberts I was having similar thoughts about the file cleanup after i submitted thepr. Just rebased and removed them from this latest one, I'll submit a separate one for those.

Good catch on the mono commit. I meant that in a joking manner (monkey-droppings) with the intention of removing their old format files since they now support the same files as vs.

Looks like travis is still the only one running, atleast on this PR. I had a similar issue on my fork though (Travis being the problem in my case). To fix it I had to remove the hook for it, and re-add it from github.

@tonyroberts what are your thoughts ongit fast-forward for merges? I personally use a combination of bothgit ff and merge-commits depending on the change. Simple changes (1 or 2 small commits) I fastforward, and more complex ones getmerge-committed.

@vmuriart cool, I'll merge this now and take a look at why the commit hooks aren't working later. I'll try just recreating it as you suggest. Thanks for doing this!

@vmuriart wrt ff, it really depends on the situation. For simple changes I prefer to ff where possible, but when adding significant new feature or a larger set of changes I prefer to use a feature branch and keep the merge commit - so sounds like we're thinking along the same lines :)

@vmuriart@tonyroberts the indent(ation) style for curly braces is a mess even after merge. Here are 2 contradictory examples:

Allman style:
https://github.com/pythonnet/pythonnet/pull/205/files#diff-1b72bb3fa8d022b65bf52c6d695a6562R44

K&R style:
https://github.com/pythonnet/pythonnet/pull/205/files#diff-0ac34f0651a9febc4d8713852516ea6cR50

Good catch. Not sure why the linter's didn't pick it up.

They should all be defaulting the K&R style since that's VS's default.

On Mon, Apr 18, 2016 at 10:50 AM, denfromufanotifications@github.com
wrote:

@vmuriarthttps://github.com/vmuriart@tonyroberts
https://github.com/tonyroberts the indent(ation) style for curly braces
is a mess even after merge. Here are 2 contradictory examples:

Allman style:

https://github.com/pythonnet/pythonnet/pull/205/files#diff-1b72bb3fa8d022b65bf52c6d695a6562R44

K&R style:

https://github.com/pythonnet/pythonnet/pull/205/files#diff-0ac34f0651a9febc4d8713852516ea6cR50

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#205 (comment)

Ah, just realized whats going on.
I only corrected the formatting on the.cs and.py files for bracketing
and such.
The whitespacing was done to all files. The file you pointed out as being
inconsistent was a.c file that only got the trailing-whitespace
treatment.

On Mon, Apr 18, 2016 at 11:32 AM, Victor Uriartevmuriart@gmail.com wrote:

Good catch. Not sure why the linter's didn't pick it up.

They should all be defaulting the K&R style since that's VS's default.

On Mon, Apr 18, 2016 at 10:50 AM, denfromufanotifications@github.com
wrote:

@vmuriarthttps://github.com/vmuriart@tonyroberts
https://github.com/tonyroberts the indent(ation) style for curly
braces is a mess even after merge. Here are 2 contradictory examples:

Allman style:

https://github.com/pythonnet/pythonnet/pull/205/files#diff-1b72bb3fa8d022b65bf52c6d695a6562R44

K&R style:

https://github.com/pythonnet/pythonnet/pull/205/files#diff-0ac34f0651a9febc4d8713852516ea6cR50

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#205 (comment)

Didn't realize that there were only 2.c files. Had i known I wouldn't have skipped them...

@vmuriart@tonyroberts I think this PR should include oneeditconfig settings file for other IDEs such as Atom, Sublime, VS Code, MonoDevelop, NPD++. See example here:

https://github.com/OmniSharp/omnisharp-roslyn/blob/dev/.editorconfig

I forgot to add the.editorconfig but I agree. I can include one with thepr to remove some of the old files