If errors are returned in addition to completion suggestions, print them
Needed for https://github.com/Valloric/ycmd/pull/198
This maintains the previous client behaviour when the semantic completer throws an exception.
[RFC] YCM Client support for FixIt commands
This change provides the client-side support in YouCompleteMe for vim providing a new :YcmFixIt command which applies changes to the vim buffer to implement trivial fixes to common coding errors where the completer provides instructions on how to fix a diagnostic. A note is added "(FixIt)" to the diagnostic text echo'd in vim when a FixIt is available.
While this may seem out of the scope of ycmd/YouCompleteMe (as a completion engine), I think it is a really useful feature, and provided straight out of libclang. so I'm sending this slightly incomplete PR (along with the associated ycmd change) to see what the appetite is within the user and maintainer community, and to get feedback on the approach.
I know that I need to write some tests, and perhaps tidy up some TODOs, but I would really appreciate any feedback on the approach. Also, I should confess that I haven't yet run the existing tests as I'm having trouble getting them to run on my mac. Hoping that travis will help me out :)
I know I also need to update the readme.
Testing has been performed manually by going through the list of .c, .cpp and .m files in clang's tests/FixIt folder and ensuring that by hitting :YcmFixIt (actually "@:" a lot!) on each diagnostic, the diagnostic went away (assuming a FixIt was available). I also mangled a number of the clang test such that the fix was spread across multiple lines, etc.
I also haven't tested this with completers other than clang completer (due to having trouble one with diagnostics getting them to work) , but of course I will prior to this being ready to merge.
I also understand that adding the vim modelines might be divisive, but the standard in this project doesn't match my usual setting :) Happy to remove them if people react angrily.
Once again thanks for the time and a great (and improving!) product.
I have signed the CLA
Demo:
Fix the following cases where the completion is not triggered for
the next typed character:
- moving vertically in insert mode,
- removing a character and entering insert mode.
Updating default semantic hooks.
The documentation was updated to be in sync with ycmd @bfcfa21,
regarding default semantic hooks defined in ycmd's completer_utils.py.
Executing the check_core_version.py script with SafePopen and stdin to
PIPE raises an error in Vim on Windows. Since the stdin option is only
useful when starting the ycmd server, it is only set in this case.
Redraw the screen before displaying a message
There has been several complaints about the message "ValueError: File is less than 5 lines long; not compiling". See issues #814, #1364, #1544. In fact, I believe the issue is not the message itself but the infamous "Press ENTER or type command to continue" prompt when editing a new C-family file.
For example, if I create the file `foo.c`, Vim will display the line `"foo.c" [New file]` and then YouCompleteMe will display `ValueError: File is less than 5 lines long; not compiling`. Since there are now two lines, the hit-enter message is prompted. By redrawing the screen just before displaying the message from YouCompleteMe, only one line appears and we avoid this behavior.
Tested on Linux and Windows.
CLA signed.
Fix check condition for setting omnifunction
I had the check for the omnifunc set backwards. I will start to see if we can start testing the vimscript layer as well. I have signed the CLA.
Fix completer available
Sorry, I deleted the branch on github by mistake. Here is the same changes from #1530 plus a buffer local variable, so we don't try to set the `omnifunc` everytime we enter insert mode. I signed the CLA.
Another way in which the commit d768447 forced the client to wait for
the server to start was the UpdateDiagnosticNotifications call from the
FileReadyToParse which is called right after a buffer is loaded. In any
way if we don't have any previous FileReadyToParse request done for the
current file we bail out, so we we can wait for a FileReadyToParse
response to be available before asking if a completer is usable for the
current filetype.
ref: #1529
When we enter a new buffer we need to know if the ycmd server has a
native completer for the current filetype, this means that when we start
vim we need to know if the server has a completer available for the
buffer which means that we have to wait for the server to be up and
running. To mitigate this defer the setting of the omnifunction closer
to its need which is when we enter insert mode; this should give room
for the ycmd server to start before we ask for anything or at least
should reduce the time waiting.
ref: #1529
Previously we were checking if the `hook.py` file existed for the given
filetype. ycmd has an endpoint for checking if given a filetype a
semantic completer is available. To avoid redundant requests we cache
those requests for every filetype. A semantic engine cannot be added
*after* the ycmd server is started so to avoid redundant requests we
cache those requests for every filetype and we clear the cache at server
setup, in this way if we issue a `YcmRestartServer` command the server
will be setup again and if a semantic completer is available we can use
it. Should fix#1284.
