Check explicitely that Vim is compiled with Python support.
Attempt to load Python 3 before Python 2 since only one can be loaded at
a time on some platforms. Return an appropriate error if unable to load
both.
Use the timers feature to display diagnostics asynchronously instead of waiting
for an autocommand to trigger.
Increase Vim version requirement to 7.4.1578.
Drop the CursorHold and CursorHoldI autocommands.
Parse buffer on the TextChanged autocommand instead of CursorMoved.
YCM should start the same whether Vim is running in GUI or not. Otherwise, this
makes it difficult for other plugins to interact with YCM at startup because
they can't predict how YCM will start unless they also check if Vim is running
in GUI which is unreasonable. Since we can't load it at Vim startup because of
a deadlock issue, we should always defer it at the VimEnter event.
This is another attempt at:
https://github.com/Valloric/YouCompleteMe/pull/2473
Which removed the apparently flawed attempt at "lazy" loading of YCM.
While it fails to get the load out of the critical startup path, it
*does* serve the useful purpose when starting up gvim of avoiding a
deadlock situation in gvim.
So, this time, we keep VimEnter, but only for the gui-starting case. We
update the comment to explain what is actually happening. And we can
keep the docs about how to defer loading.
As discussed in https://github.com/Valloric/YouCompleteMe/pull/2454,
this code doesn't do what it claims to do on the surface, so we should
delete it.
I'll follow up with a commit to explain in the README how to actually
defer loading of the plug-in.
Support lazy loading with :packadd.
- [X] I have read and understood YCM's [CONTRIBUTING][cont] document.
- [X] I have read and understood YCM's [CODE_OF_CONDUCT][code] document.
- [X] I have included tests for the changes in my PR. If not, I have included a
rationale for why I haven't.
- [X] **I understand my PR may be closed if it becomes obvious I didn't
actually perform all of these steps.**
# Why this change is necessary and useful
Vim recently has introduced a new feature called 'packages', which
permits, among the rest, to disable automatic loading a plugin at
startup. Plugins that are disabled at startup may be manually loaded
during a session using `:packadd` (see `:h packages`, `:h :packadd`).
Of course, a plugin that is loaded after startup cannot rely on VimEnter
events.
In order to support lazy loading YCM, check whether YCM is sourced
during startup or at a later time. In the former case, define an
autocommand as before; in the latter case, enable YCM immediately.
Why would one want to load YCM lazily? I use YCM only for certain file
types (Python), and I prefer not to have pop up menus appearing
all the time for other file types. In my workflow, I may enable YCM only
if I start Vim for Python coding sessions.
Tests not included because the change is in VimScript code only, and
testing this feature is not trivial.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/2084)
<!-- Reviewable:end -->
Display an error message to the user depending on the status code
returned by the ycmd server.
Remove ycm_core checks in plugin/youcompleteme.vim. These checks are
now done by the ycmd server.
Do not start a separate process to check the core version but rely on
ycmd returning a specific exit code. This slightly improves the Vim
startup time.
Vim recently has introduced a new feature called 'packages', which
permits, among the rest, to disable automatic loading a plugin at
startup. Plugins that are disabled at startup may be manually loaded
during a session using :packadd (see :h packages, :h :packadd). Of
course, a plugin that is loaded after startup cannot rely on VimEnter
events.
In order to support lazy loading YCM, check whether YCM is sourced
during startup or at a later time. In the former case, define an
autocommand as before; in the latter case, enable YCM immediately.
The user's 'cpoptions' are saved and restored when this script finishes
normally, however there are some cases where this script finishes early,
and where the user's 'cpoptions' are not restored beforehand.
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.
This option existed so that the user can tweak it if they found the default idle
timeout too short, for instance if they leave their machine on over the weekend.
This use case is now covered by the new YcmdKeepalive system that pings ycmd
every 10 minutes as long as Vim is running. This prevents ycmd shutting down if
one leaves their Vim instance alone for a long time.
Thus the old option is useless now; ycmd now shuts down after 3 hours of
inactivity, which should only ever happen when its corresponding Vim instance
has shut down abnormally.
