After pressing a key triggering the reparse takes very long
r4nt opened this issue · comments
When I enter text, it takes multiple seconds for the YCM command to be issued. The following logs are generated by:
export LIBCLANG_TIMING=1
emacs -nw .../snip.cc
Looking at ycmd-server
"Received completion request" comes pretty much instantly when hitting a key, and then it takes 2 seconds until the FileReadyToParse comes in.
2015-01-29 12:54:17,514 - INFO - Received completion request
2015-01-29 12:54:17,515 - DEBUG - Using filetype completion: False
2015-01-29 12:54:19,318 - INFO - Received event notification
2015-01-29 12:54:19,318 - DEBUG - Event name: FileReadyToParse
2015-01-29 12:54:19,319 - INFO - Adding buffer identifiers for file: snip.cc
Reparsing snip.cc: 0.1558 (100.0%) 0.0241 (100.0%) 0.1799 (100.0%) 0.2296 (100.0%)
@Valloric just fyi
What are your values for ycmd-parse-conditions and ycmd-idle-change-delay?
Ok, that was a headdesk moment. I had my ycmd-idle-change-delay set to 2 seconds (because of interference of parsing with completion).
The problem is that when I reduce that, I get very very strange behavior from emacs:
(setq company-idle-delay 0)
(setq ycmd-idle-change-delay 0.2)
(add-to-list 'ycmd-parse-conditions 'idle-change)
With this configuration, both completion and re-parsing works fine, but I get super strange artefacts in emacs while doing code completion:
When I type:
someFun
this triggers completion, and then the parsing seems to finish and pulls the line below up, it looks like this:
Element element;
unsigned offset = ...
I type "ele", which triggers completion of "element", and then emacs looks like this:
Element element;
ele unsigned offset = ...
The moment I hit a cursor key, it's back to:
Element element;
ele
unsigned offset = ...
Additional info: only happens in emacs -nw
FWIW I'm seeing the same behavior. I'll take a look at it.
Are you using flycheck? If so, do you see this problem if you disable flycheck? There seems to be a correlation between flycheck and this behavior, though I don't know the root cause yet.
@abingham - yep, this only happens when the flycheck diagnostic comes back while I'm inside the pop-up for the code completion.
Any ideas? Should I file bugs against flycheck / company? This is pretty much the last piece in the puzzle to have completely awesome code completion and syntax checking (and thanks very much for all your work so far, it's truly amazing :D )
Sorry, I haven't had any time to spend on this...just started a new contract. You could try checking with flycheck and/or company to see if there are any known issues. The flycheck guy has told me that he won't support ycmd-related issues because we're doing things of which he doesn't approve (i.e. using flycheck in adventurous ways), but maybe he'll look into it.
Hopefully I'll have some time soon to poke around on this.
And thanks for the gracious words! Thank you, too, for your help making emacs-ycmd the tool that it is. Without patient and persistent colleagues like you I wouldn't have pushed it nearly as far as we have.
Ok, figured out this is flycheck/flycheck#526
Workaround is:
(setq flycheck-indication-mode nil)
Brilliant! I'll keep this open as a reminder to myself to add a note to the README.
Even better is:
(when (not (display-graphic-p))
(setq flycheck-indication-mode nil))
I'll probably add that into our local config...
I've updated the README with information from this issue, so I think we're done with it.