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
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.
This is required to allow the ycmd GetType and GetParent subcommands to echo
their reults in vim. The apporach is to display any text returned from a
subcommand in the 'message' property assuming that the command is not a known
'GoTo' command.
It appears to address numerous amount of issues, including: #812, #801, #887.
Proposed solution uses dummy sign which is placed before updating
diagnostic signs and unplaced afterwards, which eliminates any
flickering. Also, it not just unplace all, it unplaces only that marks
that are changed, so performance should not be an issue in case of many
diagnostic messages.
It's common solution that can be found in some vim plugins that manage
signatures.
Signed-off-by: Stanislav Seletskiy <s.seletskiy@gmail.com>
This commit is the YCM-client part of the support. The ycmd support is
already done.
We now need per-language identifier regexes in ycmd (see
identifier_utils.py). There's some for HTML, CSS and the generic regex
that was used for everything until now. Pull requests welcome for other
languages.
Fixes#86.
Issued here https://github.com/Valloric/YouCompleteMe/issues/1069
To reproduce:
1. Create any file with unicode character on its filename, e.g `Ω.c`
2. Open the file and start adding codes until >5 lines (i.e ycm start compiling)
3. YCM will crash due to unicode encoding error. See issue referenced above for complete log.
I love YCM's auto popup with keyword completion when power typing but
would rather not have semantic completion activate unless I really want
it to (most semantic completers are somewhat slow and sometimes end up
breaking my flow). When in API exploration mode, I don't mind having
to press C-Space to force completion and wait a bit more.
Unless I'm mistaken, the current code does not allow wildcards in the
specification of filetypes on which to disable automatic semantic
completion. This change allows the use of '*' to disable automatic
semantic completion in all files.
- OmniCompleter is now more similar to other Completers.
- CompletionRequest doesn't store start_column anymore.
- Calling BuildRequestData only once per request.
Crash handling code tried to read stderr log file, but the file can be deleted
by the server befor we get to look at it. In such a case, we post a different
error message (without the log output).
Point is we do our best to get the error output if the user doesn't have
g:ycm_server_keep_logfiles set. If we can't get the logfile, oh well. We tell
the user to set that flag if they care.
Fixes#974.
We now make sure we don't terminate ycmd if we skipped a watchdog wakeup
time. If we skipped a check, that means the machine probably went to sleep and
the client might still actually be up. In such cases, we give it one more wait
interval to contact us before we die.
Cygwin should not call OmniSharpServer with mono
Update OmniSharpServer submodule for new client path mode parameter
Pass client path mode to OmniSharpServer on run
Previously, we'd just use json.dumps() to dump out JSON. By default,
ensure_ascii is set to true and non-ASCII chars are encoded as \uXXXX.
Problems seem to happen with other text in the data then not being utf8. I'm not
sure why, still can't repro. This should go away now that we explicitly build a
unicode string which we then encode as utf8.
Hopefully fixes#821.
