When I initially released this project, I released it under my own copyright. I
have since then worked on it in my 20% time at Google (and want to continue
doing this) and my life becomes much simpler if the copyright is Google's.
From the perspective of how this project is run and managed, **NOTHING**
changes. YCM is not a Google product, merely a project run by someone who just
happens to work for Google.
Please note that the license of the project is **NOT** changing.
People sending in future pull requests will have to sign the Google
[CLA](https://developers.google.com/open-source/cla/individual) (you can sign
online at the bottom of that page) before those pull requests could be merged
in. People who sent in pull requests that were merged in the past will get an
email from me asking them to sign the CLA as well.
We pass shell=True to Popen so that OmniSharp is not started inside a
new visible window under Windows. And since we use shell=True, we pass
the command to execute as a string, as recommended by Python's docs
(also, it won't work when passed as a sequence anyway :) ).
When loading the Omnisharp server, YCM tries to find a suitable solution
file to feed it. Instead of giving up when finding multiple solution
files, it now tries to find one named like the edited files' folder at
the solution level, e.g. if we have bla/Project.sln and we are editing
bla/Project/Folder/Whatever/File.cs, we use bla/Project.sln.
The server is multi-threaded and will spawn a new thread for each new request.
Thus, the completers need not manage their own threads or even provide async
APIs; we _want_ them to block because now were implementing the request-response
networking API.
The client gets the async API through the network (i.e., it can do something
else while the request is pending).
The not found message used to instruct users on how to install the OmniSharp completer was using an underscore while the argument to the install script uses a hyphen. The message now uses the correct naming format.
Vim is not thread-safe so posting a message to Vim from a non-GUI thread causes
a crash *sometimes*. I was aware of this problem before, but didn't catch this
instance of it in code review.
Fixes#479.
