Is there a specific API document for ycmd? I tried looking through the code base and did not see anything explicit. For emacs support the implementation will have to be in elisp, so having a python independent way of describing the API would be helpful.
I'm still in the process of writing API docs[1], but I did write a pretty thorough example client[2] that demonstrates how to talk to ycmd. It echos out all the chatter between the client and server and even pretty-prints and syntax-highlights the requests and responses. It should be pretty easy to understand how things work.
Author of YCM here; supporting emacs is one of the big reasons why ycmd is now vim-agnostic and targeting other editors. I don't use emacs and never have, but plenty of people I respect do and they all say they'd love to see something like YCM for their editor of choice.
Problem is, I know nothing of emacs scripting and have even less time to maintain Yet Another open-source project. So if I end up being the person who writes such a client, it will be shitty.
I'm really hoping someone from the emacs community takes the lead on building a ycmd client. I'd provide any and all support they'd need.
> So I cloned the repo, ran install.sh and got prompted to run the git submodule checkout for jedi the first time I opened a python file.
Yep, I added that check to better support the use case of people checking out the repo themselves instead of using Vundle (which will checkout the git submodules for you automatically).
Most complaints here are about the installation procedure. I tried to make it as easy as possible, but the root of the problem is that you _have to_ compile the ycm_core module so that completion is fast. There's no going around it. The compiled module is the main reason why YCM is so fast when you get it configured.
Other than complicated/rare configurations, installing YCM is IMO not that difficult. The _only_ difference between installing any "average" plugin with Vundle/Pathogen and YCM is running ./install.sh from the YCM directory after you pull it in. That's it. The script will download dependencies for you (libclang), run cmake, make and all the other tools so that everything is installed correctly. It will clean up after itself too. It's pretty hand-holdy so it will tell you if you need to install something (like CMake).
The docs are pretty extensive so you should not get stuck anywhere even if you encounter problems.
I'm happy to hear suggestions on how to further improve the installation procedure. As always, pull requests are welcome too.
YCM too goes out of its way to inform you if you missed something you needed to do, like create a ycm_extra_conf.py file with your build flags (if you want the C-family semantic completion to work) because YCM can't conjure out of the air all the include paths and such needed to compile your project. There's no going around this, a real compiler is used to build the AST so we need the compiler flags.
All in all, if the installation procedure is the main complaint, I'm happy (not really, but you get the point) because that means that actually _using_ the plugin is a good experience (I hope). The installation you go through once and forget about; you use the plugin every day.
Here are excerpts from the FAQ about some of the other things people have brought up:
# Why isn't YCM just written in plain VimScript, FFS?
Because of the identifier completion engine and subsequence-based filtering. Let's say you have many dozens of files open in a single Vim instance (I often do); the identifier-based engine then needs to store thousands (if not tens of thousands) of identifiers in its internal data-structures. When the user types, YCM needs to perform subsequence-based filtering on all of those identifiers (every single one!) in less than 10 milliseconds.
I'm sorry, but that level of performance is just plain impossible to achieve with VimScript. I've tried, and the language is just too slow. No, you can't get acceptable performance even if you limit yourself to just the identifiers in the current file and simple prefix-based fitering.
# Why does YCM demand such a recent version of Vim?
During YCM's development several show-stopper bugs were encountered in Vim. Those needed to be fixed upstream (and were). A few months after those bugs were fixed, Vim trunk landed the pyeval() function which improved YCM performance even more since less time was spent serializing and deserializing data between Vim and the embedded Python interpreter. A few critical bugfixes for pyeval() landed in Vim 7.3.584 (and a few commits before that).
Couldn't you ship a several already compiled binaries for major OSes? What do you do during compilation (and do you have to do this during compilation instead of on runtime) that makes it impossible?
I'm not using VIM anymore, so the question is just at out of curiosity :)
Indeed, and if it's about saving on duplicating libraries, that's less important to me than saving on installation time. I don't care if it loads up 20 megs of duplicated libraries because you had to hard-link them in. I have loads of RAM, very little time to set things up.
Anyone know of a tool or system out there that automates the creation of binaries for several systems and then adds them to a key-value file with arch : binary_file_name pairs that can be consumed by an install script or curl pipe to shell install.
Are you familiar with NeoBundle? It's mostly a drop-in replacement for Vundle, but it has support for post-installation hooks. This could potentially make it a one-step install (assuming NeoBundle was already installed).
I use NeoBundle to run the YouCompleteMe module build upon installation. Works great. Especially since the build is triggered by a single simple command. (People really complain about that being hard?)
Yeah I don't get it - I had zero issues with installation (and I usually find a way to screw everything up). Can you post your YouCompleteMe install block for NeoBundle?
"Super-quick" was intended to be a bit tongue-in-cheek, although compared to the Full Installation Guide (it's in the docs), trust me, the "super-quick" installation really is super-quick.
All in all, if the installation procedure is the main complaint, I'm happy (not really, but you get the point) because that means that actually _using_ the plugin is a good experience (I hope). The installation you go through once and forget about; you use the plugin every day.
Except, I don't. I haven't installed it because I have a feeling this will be way more hassle than it looks (a feeling validated by several comments in this thread) and I don't have the time to do that kind of stuff.
Please let us know when installation is less of a kluge.
I followed your full install directions to a T and I'm getting "YouCompleteMe unavailable: ycm_core too old, PLEASE RECOMPILE ycm_core" on Vim start-up. This doesn't appear to be a Python version issue (everything is showing 2.7) and I downloaded the Clang binaries as directed.
To be honest, I found it completely reasonable, and as quick as a compilation step could be. I didn't install it yet due to the new Vim version dependency, but I will as soon as I get the new Vim version.
Having both python2 and python3 enabled in your Vim can lead to nasty results. I remember Vim used to crash if you source a python2 file into it (thus starting the python2 interpreter) and a python3 file some time later (thus also starting the python3 interpreter). They didn't seem to like existing in the same process.
There's been a few requests for keeping the semantic completion engine but turning off the identifier-based engine (this is the "always-on" part) so the feature will be implemented some time soon.
I haven't tried, but I've done everything possible to keep both the code and the build system cross-platform. I've written OSS cross-platform C++ code using Boost before (with CMake as the build system) and had it working on Windows, Mac, Linux and FreeBSD without modification. I've applied the same principles here, just haven't tested it on Windows or written docs on how to get it working there. But it's doable, certainly.
It doesn't really depend on MacVim, that's just a binary distribution of Vim for Macs that is proven to work.
Vim from Homebrew doesn't work though, something is wrong with the way Homebrew configures/builds Vim (don't know what though).
You can certainly build a Vim from source for Mac and have that work well with YCM, the only question is why would someone go through the trouble of doing so when MacVim does it for you.
Even if you prefer using Vim in the console and don't like the GUI, MacVim.app has a normal Vim binary inside it that you can call.
Works amazing. Always had a problem with having to press a button to autocomplete. The cognitive reflection of "okay, I want help completing this word" usually defeats the speed improvement for me.
> It doesn't really depend on MacVim, that's just a binary distribution of Vim for Macs that is proven to work.
Ah okay - the README gave me a very different impression. Either way using the packaged MacVim binary via the mvim script is preferable, for reasons you've elaborated on.
> why would someone go through the trouble of doing so when MacVim does it for you.
Commandline lovers love trouble, are often not found browsing .dmg offerings?
