[READY] Do not open location list at the bottom of screen
The location list is specific to the current window so it should be opened inside the current window (default behavior), not to full width at the bottom of the screen (with `:botright`).
<!-- 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/2781)
<!-- Reviewable:end -->
[READY] Update ycmd
This new version of ycmd includes the following changes:
- PR Valloric/ycmd#795: add option to make relative paths in flags from extra conf absolute;
- PR Valloric/ycmd#802: fix compilation on Haiku;
- PR Valloric/ycmd#804: add libclang detection on FreeBSD;
- PR Valloric/ycmd#808: write python used during build before installing completers;
- PR Valloric/ycmd#810: support unknown languages from tags;
- PR Valloric/ycmd#811: update Universal Ctags languages list;
- PR Valloric/ycmd#814: resolve symlinks in extra conf glob patterns;
- PR Valloric/ycmd#815: update JediHTTP;
- PR Valloric/ycmd#816: update Boost to 1.65.0;
- PR Valloric/ycmd#819: filter and sort candidates when query is empty;
- PR Valloric/ycmd#820: improve LLVM root path search for prebuilt binaries;
- PR Valloric/ycmd#822: inline critical utility functions;
- PR Valloric/ycmd#824: do not sort header paths in filename completer;
- PR Valloric/ycmd#825: implement partial sorting;
- PR Valloric/ycmd#830: add max_num_candidates option;
- PR Valloric/ycmd#831: fix multiline comments and strings issues;
- PR Valloric/ycmd#832: update Clang to 5.0.0.
The `g:ycm_max_num_candidates` and `g:ycm_max_num_identifier_candidates` options are added to the documentation.
The link to ycmd extra conf is updated.
Fixes#2562.
<!-- 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/2768)
<!-- Reviewable:end -->
Include following changes:
- add option to make relative paths in flags from extra
conf absolute;
- fix compilation on Haiku;
- add libclang detection on FreeBSD;
- write python used during build before installing
completers;
- support unknown languages from tags;
- update Universal Ctags languages list;
- resolve symlinks in extra conf glob patterns;
- update JediHTTP;
- update Boost to 1.65.0;
- filter and sort candidates when query is empty;
- improve LLVM root path search for prebuilt binaries;
- inline critical utility functions;
- do not sort header paths in filename completer;
- implement partial sorting;
- add max_num_candidates option;
- fix multiline comments and strings issues;
- update Clang to 5.0.0.
[READY] Update ClearCompilationFlagCache docs
Update the documentation for the `ClearCompilationFlagCache` subcommand by taking into account that:
- the `do_cache` parameter is set to `True` by default;
- the flags from the compilation database are also cached;
- restarting the server clears the cache.
<!-- 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/2763)
<!-- Reviewable:end -->
[READY] Improve error message when server crashes
This PR improves the error message displayed to the user when the server unexpectedly crashes by giving the exact command to type to open the server logfile.
We could go further by automatically opening the server logfile but this is too disruptive in my opinion.
<!-- 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/2752)
<!-- Reviewable:end -->
[READY] Do not read server standard error
When the ycmd server crashes, we read its standard error and log the result. Unfortunately, this blocks Vim if a sub-server is still running after the crash (e.g. JediHTTP). In that case, the only way to unblock Vim is to manually kill the sub-server.
We could fix the issue by writing some (non-trivial) code that reads ycmd `stderr` without blocking but instead we simply don't read it at all. The drawback is small: [ycmd immediately redirects its `stdout` and `stderr` to logfiles at startup](ff255aed4a/ycmd/__main__.py (L150-L153)). In other words, reading its `stderr` is only useful if ycmd crashed before the redirection. This is something that should never happen.
<!-- 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/2750)
<!-- Reviewable:end -->
[READY] Insert keys at the start of the typeahead buffer
When sending keys to Vim through `feedkeys`, these keys are by default added to the end of the typeahead buffer. If there are already keys in the buffer, they will be processed first and may change the state that our keys combination was sent for. For instance, `<C-X><C-U><C-P>` may be sent in normal mode instead of insert mode (issue #2731) or `<C-e>` outside of completion mode (issue #2732). We avoid that by inserting the keys at the start of the typeahead buffer with the `i` option.
Fixes#2731.
Fixes#2732.
<!-- 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/2733)
<!-- Reviewable:end -->
When sending keys to Vim, they are by default added to the end of the typeahead
buffer. If there are already keys in the buffer, they will be processed first
and may change the state that our keys combination was sent for (e.g.
<C-X><C-U><C-P> in normal mode instead of insert mode or <C-e> outside of
completion mode). We avoid that by inserting the keys at the start of the
typeahead buffer.
[RFC] Add a more obvious explanation for users of the default system Vim on macOS
# 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.**
No tests because we don't have Vimscript tests. But I tested:
* System Vim on macOS:
```
BeniMac:YouCompleteMe-Clean ben$ /usr/bin/vi
YouCompleteMe unavailable: requires Vim 7.4.1578+.
Info: You appear to be running the default system Vim on macOS. It reports as patch 8056, but it is really older than 1578. Please consider MacVim, homebrew Vim or a self-built Vim that satisfies the minimum requirement.
Press ENTER or type command to continue
```
* Manually built too-old Vim on macOS (regression test)
```
BeniMac:vim ben$ ./src/vim
YouCompleteMe unavailable: requires Vim 7.4.1578+.
Press ENTER or type command to continue
BeniMac:vim ben$
```
* MacVim (latest) works
* Homebrew Vim (latest) works
* Whatever random Vim I was using before works
# Why this change is necessary and useful
As the comment says, and referred in [this issue]( https://github.com/Valloric/YouCompleteMe/issues/2721#issuecomment-317272969) and [this comment](https://github.com/Valloric/YouCompleteMe/issues/549#issuecomment-317272203) users of macOS are being flummoxed by the reporting of its version on the launch screen as some bogus patch number. I guess Apple patched it for some reason (such as their OS protection or something), and just chose a random high number (or perhaps some v8 back patch, who knows).
Anyway, a specific error message for such users means they can get a working system without reporting to us, but it's our overhead to maintain the extra code. So RFC for that reason.
[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/2728)
<!-- Reviewable:end -->
[READY] Check completefunc when forcing semantic completion
When `completefunc` is not set (because YCM is not allowed to complete in the current buffer or the server failed to start) and semantic completion is forced with `<C-Space>`, Vim returns the following error:
```
E764: Option 'completefunc' is not set
```
This happens because we don't check if `completefunc` is set to `youcompleteme#CompleteFunc` in that case.
To completely avoid this issue, we always set the `completefunc` before invoking it. This may look inefficient but, in practice, the performance cost is almost nil.
<!-- 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/2722)
<!-- Reviewable:end -->
Include following changes:
- update bottle to 0.12.13;
- update Clang to 4.0.1;
- fix compilation with Clang 3.4;
- only configure tests and benchmarks if required;
- fix finding Python library in virtualenv;
- switch back to Boost regex.
[READY] Fix unicode warning when unloading buffer on Python 2
When a buffer is unloaded, [we compare its name to the current buffer one in the `BuildRequestData` function](5b89d41832/python/ycm/client/base_request.py (L160)). This raises a unicode warning on Python 2 when the deleted buffer name contains non-ASCII characters because the deleted buffer name is a byte object while the current buffer name is a unicode one.
I updated the `BufferUnload` test to show the issue. I'll send the fix once the builds failed.
<!-- 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/2710)
<!-- Reviewable:end -->
[READY] Do not cache omnifunc on FileReadyToParse event
We currently cache the omnifunc when the file is ready to be parsed i.e. on the `FileType`, `BufEnter` events and possibly on `InsertLeave` and `TextChanged`. That's problematic if the omnifunc is modified after these events and the user is requesting completions from it. This was the cause of issue https://github.com/Valloric/YouCompleteMe/issues/1027 but is not relevant anymore because we now always parse the file on the `BufEnter` event and thus the omnifunc is properly updated after switching buffers. Still, it's more correct to cache the omnifunc inside the `ShouldUseNow` method since `ComputeCandidatesInner` is called immediately after. Performance is not a concern: it takes less than 10 μs to get the omnifunc.
Fixes https://github.com/Valloric/YouCompleteMe/issues/1027.
<!-- 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/2708)
<!-- Reviewable:end -->
[READY] Restore cursor position after omnifunc call
When compiled without C-family support, YCM will use the default omnifunc from Vim (`ccomplete#Complete`) to provide semantic completion. This omnifunc calls [`searchdecl`](http://vimdoc.sourceforge.net/htmldoc/eval.html#searchdecl()) to find a declaration, which is supposed to move the cursor to that declaration. However, the cursor is not moved when called through the omni completion mapping (`CTRL-X CTRL-O`). Since PR https://github.com/Valloric/YouCompleteMe/pull/2657, YCM calls the omnifunc outside completion mode and thus the cursor is moved to the found declaration after typing `.` or `->`.
Considering this `searchdecl` trick may be used by other omnifuncs, we fix the issue by always restoring the cursor position after calling the omnifunc.
Fixes#2698.
<!-- 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/2707)
<!-- Reviewable:end -->
Calling directly the omnifunc may move the cursor position. This is the case
with the default Vim omnifunc for C-family languages (ccomplete#Complete) which
calls searchdecl to find a declaration. This function is supposed to move the
cursor to the found declaration but it doesn't when called through the omni
completion mapping (CTRL-X CTRL-O). So, we restore the cursor position after
calling the omnifunc.
[READY] Rewrite omnifunc tests
Change the `VimBuffer` object to accept a Python function as its omnifunc, e.g.
```python
def Omnifunc( findstart, base ):
if findstart:
return 5
return [ 'a', 'b', 'c' ]
```
and rewrite the omnifunc tests accordingly. This reduces the amount of mocking done directly in these tests.
Also, extend the `ToBytesOnPY2` function to lists and dictionaries so that, instead of having to write
```python
[ ToBytesOnPY2( 'a' ), ToBytesOnPY2( 'b' ), ToBytesOnPY2( 'c' ) ]
```
in tests, one can write:
```python
ToBytesOnPY2( [ 'a', 'b', 'c' ] )
```
<!-- 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/2701)
<!-- Reviewable:end -->
[READY] Fix unicode warning when jumping on Python 2
On Python 2, jumping in a file whose path contains non-ASCII characters raises the following warnings:
```
Error detected while processing function <SNR>26_CompleterCommand:
line 18:
python\ycm\vimsupport.py:400: UnicodeWarning: Unicode unequal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
if filename != GetCurrentBufferFilepath():
python\ycm\vimsupport.py:375: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
if win.buffer.name == filepath:
```
This happens because, in the `JumpToLocation` function, we are comparing a unicode object (`filename` and `filepath`) with a Vim buffer name (`vim.current.buffer.name` returned by `GetCurrentBufferFilepath` and `win.buffer.name` where `win` is a Vim window) which is a byte object on Python 2.
For now, this PR adds tests covering the `JumpToLocation` function with unicode paths. They will raise the warnings on Python 2 and will fail because warnings are now treated as errors in tests. I'll update the PR with the fix once the builds are done.
<!-- 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/2702)
<!-- Reviewable:end -->
The 'hidden' option is a global option, not a buffer one. If this option is
false, we should check if the 'bufhidden' option, which is local to the buffer,
is set to 'hide'. If so, the buffer can be hidden despite the 'hidden' option
being false.
