[READY] Fix smart matching example in documentation
The smart matching example is wrong: `o` can't match `ø` because `ø` is a letter on its own, not a `o` with a combining mark.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/3006)
<!-- Reviewable:end -->
Include the following changes:
- add Unicode support to the filter and sort algorithm;
- replace Boost.Python with pybind11;
- expand environment variables in extra conf options;
- make GoTo and GoToImprecise subcommands jump to declaration if cursor on
definition;
- reset prefix when setting the start column;
- send the full query to the language server completer when forced;
- improve caching behavior;
- add OrganizeImports command to Java completer;
- add Scheme identifier regex;
- update jdt.ls to 0.15.0;
- fix TypeScript diagnostics;
- optimize lines splitting for current file;
- improve TypeScript completion data;
- add GoTo and GoToDeclaration commands to TypeScript completer;
- add TSServer version to debug info;
- replace re module with regex;
- add smart diacritic matching;
- add FixIt command to TypeScript completer;
- add Format command to TypeScript completer;
- add OrganizeImports command to TypeScript completer;
- improve Java project detection heuristics;
- allow the user to manually specify a Java project path;
- improve TeX identifier regex;
- always return detailed completions in TypeScript completer;
- support FixIts in TypeScript completions;
- improve message when regex module installation fails;
- update Boost to 1.67.0;
- update godef;
- add Ctags filetype mapping for PuppetManifest.
[READY] Resend request when extra conf is loaded or ignored
When the client sends a request to the server, if an extra conf file is found that is not already white/blacklisted, the server stops processing the request and tells the client that an unknown extra conf file has been found. The client then asks the user if that file should be loaded or not. Depending on the
user's answer, the client sends a request to the server to load or ignore the extra conf file. Finally, the server loads the file or adds it to the blacklist. However, the initial request was not processed by the server and should be sent again.
Here's a demo illustrating the current situation:
![extra-conf-request-not-resent](https://user-images.githubusercontent.com/10026824/38840090-2d700936-41de-11e8-8b76-87c3eab960cc.gif)
As you can see, the file is not parsed after loading the extra conf file. With the proposed changes:
![extra-conf-request-resent](https://user-images.githubusercontent.com/10026824/38840137-67126670-41de-11e8-8707-88441ab35ac3.gif)
Fixes#2962.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/2988)
<!-- Reviewable:end -->
When the client sends a request to the server, if an extra conf file is found
that is not already white/blacklisted, the server stops processing the request
and tells the client that an unknown extra conf file has been found. The client
then asks the user if that file should be loaded or not. Depending on the
user's answer, the client sends a request to the server to load or ignore the
extra conf file. Finally, the server loads the file or adds it to the
blacklist. However, the initial request was not processed by the server and
should be sent again.
[READY] Do not return omnifunc suggestions if server crashed
We currently return unfiltered and unsorted suggestions from the omnifunc if the `filter_and_sort_candidates` request failed (generally because the server crashed). This behavior is confusing as it may let the user thinks that YCM is working (in a bad way) while in fact it doesn't. No suggestions should be returned in that case.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/2989)
<!-- Reviewable:end -->
[READY] Check if completion is allowed on character events
We should check if completion is allowed when a character is inserted or deleted like we do with the other events.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/2979)
<!-- Reviewable:end -->
[READY] Refactor server exception handling
Having to wrap all request calls with the `HandleServerException` function is inconvenient. Handle server exceptions directly in `BaseRequest`.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/2976)
<!-- Reviewable:end -->
Allow users to still trigger Vim's omnifunc through C-Space when the
g:ycm_filetype_specific_completion_to_disable option is set for the current
filetype.
[READY] Fix index error when applying a chunk at the end of file
When sending a request to the server, [we add a newline to the buffer contents to match what gets saved to disk](d3381411a0/python/ycm/vimsupport.py (L117)). If the server generates a chunk containing that newline, this chunk goes past the Vim buffer contents since there is actually no new line, which raises an `IndexError` exception when applying the chunk. We fix the issue by recomputing the end position of where the chunk is applied and by removing all trailing characters in the chunk.
Steps to reproduce the issue:
- create a `Test.java` file with the following contents:
```java
package Test;$
$
```
where `$` represents an end of line;
- issue the `:YcmCompleter Format` command.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/2951)
<!-- Reviewable:end -->
When sending a request to the server, we add a newline to the buffer contents
to match what gets saved to disk. If the server generates a chunk containing
that newline, this chunk goes past the Vim buffer contents since there is
actually no new line, which raises an IndexError exception when applying the
chunk. We fix the issue by recomputing the end position of where the chunk is
applied and by removing all trailing characters in the chunk.