[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.
[READY] Remove 7-Zip dependency from Windows instructions
7-Zip is not required anymore on Windows since we now extract libclang from our `.tar.bz` packages.
<!-- 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/2942)
<!-- Reviewable:end -->
[READY] Don't open the quickfix window after FixIt/Refactor
# PR Prelude
Thank you for working on YCM! :)
**Please complete these steps and check these boxes (by putting an `x` inside
the brackets) _before_ filing your PR:**
- [x] I have read and understood YCM's [CONTRIBUTING][cont] document.
- [x] I have read and understood YCM's [CODE_OF_CONDUCT][code] document.
- [x] I have included tests for the changes in my PR. If not, I have included a
rationale for why I haven't.
- [x] **I understand my PR may be closed if it becomes obvious I didn't
actually perform all of these steps.**
# Why this change is necessary and useful
When FixIt was originally implemented, I decided to present the quick fix list containing the set of changes made to the buffers as it was thought this would be helpful and would reassure the user that the changes we made to their code made sense and were safe. Some large part of this decision was paranoia.
Since then we're using fixit code in a lot more places and the feature is pretty mature. I personally find the opening of the quick fix window to be a bit of a pain, and I quickly end up closing it manually to reclaim the space. I have literally never used it to jump to a location that was changed.
I have received recent feedback from users that "Why is it when I do a FixIt, this annoying window appears at the bottom of the screen that I can't get rid of?". Most users who are unhappy with the result of a FixIt can, and do, use the undo command as a matter of habit.
So I propose to just not auto-display the quick fix window anymore for FixIts, Renames, etc. We continue to populate the quick fix list, however, so `:copen` can be used to inspect the results, for those power users that know about quick fix lists.
[cont]: https://github.com/Valloric/YouCompleteMe/blob/master/CONTRIBUTING.md
[code]: https://github.com/Valloric/YouCompleteMe/blob/master/CODE_OF_CONDUCT.md
<!-- 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/2926)
<!-- Reviewable:end -->
[READY] Prefix commands with python in Windows instructions
Arguments may be ignored when running the `install.py` script in a `cmd.exe` prompt if the command associated to Python files is incorrect. Update the Windows instructions by prefixing the commands with `python`.
Fixes#2929.
<!-- 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/2931)
<!-- Reviewable:end -->
[READY] Improve diagnostic matches display
There are two issues with how we display diagnostic matches. The first issue is that if the current buffer contains diagnostic matches and is split in a new window, all the matches are cleared and only matches in the new window are shown. The second issue is that if a new buffer with no diagnostic support is open in the current window and that window already contained matches then the matches are still displayed. Here's an illustration of both issues (signs are disabled):
![diagnostic-matches-issue](https://user-images.githubusercontent.com/10026824/36352338-bfeb2092-14b7-11e8-88f4-ae8cf6903304.gif)
The solution is to add an autocommand that updates matches on the `BufEnter` and `WinEnter` events. Here's the result:
![diagnostic-matches-fix](https://user-images.githubusercontent.com/10026824/36352340-c2a64a8c-14b7-11e8-8db2-4f1f54448c65.gif)
Note that it's not perfect as multiple windows of the same buffer won't be updated simultaneously. Supporting that scenario is rather tricky because we would need to go through all the windows to update the matches and switching windows can lead to a lot of issues (like interrupting visual mode) so we don't.
This PR also improves how we update matches by only displaying matches that are not already present and then clearing the remaining ones (similarly to what we do with signs; see PR https://github.com/Valloric/YouCompleteMe/pull/2915) instead of always clearing all the matches then displaying the new ones.
<!-- 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/2922)
<!-- Reviewable:end -->
[READY] Add function to capture Vim command output
Since there are now two places where we need to capture the output of a Vim command (for diagnostic signs and for syntax keywords), we should add a function for that.
<!-- 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/2921)
<!-- Reviewable:end -->
[READY] Improve diagnostic sign placement
Currently, we store internally the signs that we place in the buffer so that when we receive a new batch of diagnostics, we can efficiently add and remove signs by looking at the line positions of the stored signs. However, there is a flaw in that approach. When lines are added or removed to the buffer, Vim update the lines of the signs accordingly and thus our stored signs may not correspond anymore to the actual signs. Here's an example of the issue:
![sign-diagnostic-issue](https://user-images.githubusercontent.com/10026824/36215183-af078aea-11ab-11e8-9827-0e7ab6e4b7b5.gif)
*Where did my signs go? I want a refund!*
The solution is to not store the signs but instead get them directly from Vim each time we need to update them. This is done by parsing the output of the `:sign place` command (Vim doesn't provide an API to properly do that). The same example as above with the proposed changes:
![sign-diagnostic-fix](https://user-images.githubusercontent.com/10026824/36215595-ce3916ee-11ac-11e8-8625-d44dc6c8bd1c.gif)
*Oh, they were there.*
<!-- 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/2915)
<!-- Reviewable:end -->