Ycmd completion unavailable while parsing is in progress

[r4nt]

@Valloric - somehow vim-ycm doesn't completely disable completions during parsing, right?

@abingham - can we make emacs-ycmd somehow still take the completion request? Otherwise company seems to fall back to clang-complete, which seems strange as default behavior...

[Valloric]

somehow vim-ycm doesn't completely disable completions during parsing, right?

Well, semantic completion requests will fail, but identifier completion requests will succeed.

Note that there have been recent changes in this area; ycmd used to allow several semantic completion requests for a single C++ file to proceed, but they would serialize on the TU mutex. For codebases with huge TUs (you might know one ;)), this would sometimes result in ycmd exhausting its threads.

So since ycm-core/ycmd@c8aadd0, ycmd will only allow one C++ semantic completion request per file to proceed, while others that come in for the same file will get an HTTP error mentioning that the file is currently being parsed.

This in no way affects identifier completion requests. Those always go in parallel and are super-fast. Note that YCM (the vim client) only sends semantic completion requests after semantic triggers (like -> and .) and otherwise sends identifier completion requests.

[r4nt]

@Valloric - oh, those are different requests? I wasn't aware...

[r4nt]

(to be more precise: I wasn't aware that "semantic" and "identifier" completion are different requests).

[r4nt]

Seems like we could just fall back to identifier completion when semantic completion is not available...

[Valloric]

oh, those are different requests? I wasn't aware...

I should have been more specific. It's a bit complex... it's technically the same request from a client perspective. When a completion request comes in, the server decides whether to query the semantic engine or not based on several factors. The request is then routed to the correct engine based on the decision.

[abingham]

@r4nt I think we could easily change company-ycmd to take the completion request when parsing is ongoing. We could even make that a configurable behavior, which might make sense since everything else about company is pretty configurable.

I'm not sure if that's the right approach, though, since they can get similar behavior (i.e. not defaulting to clang-complete) removing clang-complete from their company-backends list. It might be simplest overall to warn them if we detect that both ycmd and clang are in that list.

[r4nt]

@abingham - yea, I found people who have set up company-clang as fallback in their emacs configs. I think it would be best if @Valloric could change ycmd to do the following:
If a completion request comes in that ycmd would usually answer with "error: we're still parsing", instead query the identifier completion (and perhaps give some hint of that in the reply, so the editor can show a little warning if supported).

[dgutov]

Otherwise company seems to fall back to clang-complete

company-ycmd should return stop to prefix when still parsing.

[abingham]

@r4nt That all sounds fine to me. I'll leave that for you guys to sort out.

@dgutov Is that always the case? Is there no situation in which a user might want to let control flow to another backend? We could make it configurable.

[dgutov]

@abingham Err, of course, certain users might prefer it to work differently, but I think this approach makes sense. Delegating to company-clang, doesn't.

[Valloric]

@r4nt

If a completion request comes in that ycmd would usually answer with "error: we're still parsing", instead query the identifier completion

That makes sense, but will require a bit of work. It does come with a downside: currently, you are guaranteed to get a semantic completion after a semantic trigger or nothing at all. So if you get foo after ., that object has a foo method/property. If we switch to identifier completion fallback, now you can't entirely trust this.

To be fair, semantic completion is displayed differently in the Vim pop-up menu (extra info on arguments etc) so the user will be able to tell that they're not getting semantic info.

This is probably worth doing though. Open an issue on ycmd so I don't forget. Provide a link to this issue.

[ptrv]

@r4nt @Valloric

I really prefer the way it is currently: to have the guarantee to get semantic completion after a semantic trigger. Even if it takes longer and I have to wait.

@Valloric If you want to change this behavior please make an option to switch back to the current one if the user prefers it.

[r4nt]

Added: ycm-core/ycmd#67

[r4nt]

@ptrv - yea, I think an option is the right way - it depends highly on the codebase (if you have to wait for 30 seconds, the trade-off might come out differently from when you have to wait 0.5 seconds :)

[abingham]

It seems that this issue is resolving itself elsewhere, so I'm closing this until/unless anyone has any complaints.

[r4nt]

@abingham - btw, I think all the open issues I had are now resolved - thanks a lot for your work here, it's highly appreciated :)

[abingham]

Great, thanks! Honestly when left to my own devices I tend towards "works well enough for me", and emacs-ycmd wouldn't have near the level of polish it has without the kind of input you and others have given. So keep the ideas coming.