[READY] Add --all option to README
# 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
I use the `--all` flag for every build. I know this is probably a flag that's more useful for YCM contributors than most users, but it makes sense to document it.
# No tests
It's only an update to the README, so I just tested it by eyeballing the output.
[cont]: https://github.com/Valloric/YouCompleteMe/blob/master/CONTRIBUTING.md
[code]: https://github.com/Valloric/YouCompleteMe/blob/master/CODE_OF_CONDUCT.md
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/2027)
<!-- Reviewable:end -->
[READY] Making YCM run in Vim with only python3
Since https://github.com/Valloric/ycmd/pull/358, ycmd has supported Python 3. Now's the time to make the YCM client work in Python 3 too. As with the ycmd PR, **until we merge this, no other code-changing PR should be merged.** We need to get to a state where we have green Travis for Python 3 before any other PRs start landing.
This was substantially easier than porting ycmd, but it was still a massive pain. It's likely to fail in certain corner cases, so please give this a spin!
The best way to test it out is to build a Vim that has only Python 3 support. Our wiki page on [building Vim from source](https://github.com/Valloric/YouCompleteMe/wiki/Building-Vim-from-source) is a great start; you'll probably need to change `--enable-pythoninterp` to `--enable-python3interp` and similar for `--with-python-config-dir`. Or just get yourself a beta image of Ubuntu 16.04 LTS and run it in a VM (16.04 doesn't even ship Python 2 in the base image!). You can verify that you're running the right Vim by looking at the output of `vim --version`. It should have `-python` and `+python3`.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/2016)
<!-- Reviewable:end -->
On Windows and Python 2, the full exception message from IOError
in CheckFilename will contain the filepath formatted as a unicode
string. Since the filepath is already added in the RuntimeError
message, use the strerror attribute to only display the error.
Move PostComplete tests inside a class that defines setUp and tearDown
methods. Clean YCM object in tearDown method. This fixes the error
"OSError: [WinError 6] The handle is invalid" on Windows with
Python 3.5.
Python 3 is much stricter around mixing bytes with unicode (and by
"stricter," I mean it doesn't allow it at all) so we're making
vimsupport only return `unicode` objects (`str` on py3). The idea is
that YCM (and ycmd) internals only ever deal with unicode.
[READY] Fix entries in table of contents
Rename entries of `YcmCompleter subcommands` section in table of contents so that they correspond to their sections title. Add `Miscellaneous commands` missing entry.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/2011)
<!-- Reviewable:end -->
Make headings and TOC entries have the same text.
Use Title Case for TOC entries.
Add "Miscellaneous commands" and "Functions" entries.
Set "And That's not all..." heading in bold instead.
Move "Diagnostic highlighting groups" to a third-level entry.
[READY] Rewrite SetUpPython function
This PR fixes issue #1726 by moving most of SetUpPython logic to its own module and using a try-catch-else block at the end of the function. It also prevents Python backtraces in Vim (which are really annoying) for common exceptions (`RuntimeError` and `ImportError`).
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/1994)
<!-- Reviewable:end -->
[READY] Updating to latest ycmd
Still using ycmd only in py2, but at least we can use YCM with ycmd master again.
@micbou @puremourning @vheon Try to give this one a whirl on your machines since ycmd had a ton of recent changes.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/1995)
<!-- Reviewable:end -->
[READY] Support FixIt and Refactor commands across multiple files
## Apply FixIt chunks across files
Previously, FixIts could only apply to the current buffer. Now we can apply FixIts across files, even if they are not currently open in the user's Vim. We obey existing configuration about how/where to open new files and apply changes in such a way as to not scribble the user's filesystem, and allow full undo history, like existing FixIt commands. Vim's python API actually makes this really quite easy.
To achieve this, we sort the chunks by filename, apply the existing logic unchanged. The only difference is that `ReplaceChunk` no longer implicitly assumes it applies to `vim.current.buffer`.
## Recognise 'FixIt' responses for any subcommand
Previously, we used the subcommand name to determine the type of response to expect. This coupled the client and the server and didn't allow us to apply FixIts for a "Refactor" command, or "GoTo" for a, theoretical "Find" command.
Now 'GoTo' and 'FixIt' commands don't need to start with those prefixes. For 'FixIt' we can detect the response type by looking for the 'fixits' entry in the response.
## Other changes
The `vimsupport.OpenFilename` method needed to handle the presence of Vim swap files and the various user responses. This pushed the cyclomatic complexity over the threshold, so the code was partially obfuscated to accommodate the cyclomatic complexity gods.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/1917)
<!-- Reviewable:end -->
Additionally, we restructure subcommands section to organise by
command type.
There are now a significant number of subcommands offering quite
powerful features. A flat-list of such commands is not easy for users to
discover (citation needed). Restructured into:
- GoTo commands
- Documenation/type information commands
- FixIt/refactor commands
This has the following benefits:
- features are more discoverable to the user (due to contents page
update)
- more obvious where to add new subcommand documentation
- a place to write notes which apply to multiple commands (such as
jump lists, multi-file refactor)
We simply apply the changes to each file in turn. The existing replacement
logic is unchanged, except that it now no longer implicitly assumes we are
talking about the current buffer.
If a buffer is not visible for the requested file name, we open it in
a horizontal split, make the edits, then hide the window. Because this
can cause UI flickering, and leave hidden, modified buffers around, we
issue a warning to the user stating the number of files for which we are
going to do this. We pop up the quickfix list at the end of applying
the edits to allow the user to see what we changed.
If the user opts to abort due to, say, the file being open in another
window, we simply raise an error and give up, as undoing the changes
is too complex to do programatically, but trivial to do manually in such
a rare case.
Now 'GoTo' and 'FixIt' commands don't need to start with those
prefixes. For 'FixIt' we can detect the response type by looking for
the 'fixits' entry in the response.
For 'GoTo' this is a touch harder, as there is no completely obvious
way to tell. However it is unique in this respect, so we can simply
fall back to it.
Completers returning other types of response are not supported by
this client.
