I have `g:python3_host_prog` set to the system Python, where a package
is also installed to provide the "neovim" module.
`:checkhealth provider` however displays a warning for this:
> Your virtualenv is not set up optimally.
This is because /usr/bin/python is not in /home/user/.pyenv.
I think this warning should not get displayed if host_prog_var exists.
It goes back to the initial commit (20447ba09), and is maybe only
missing the `!` there as with the previous commit.
Full output:
```
- INFO: pyenv: /home/user/.pyenv/libexec/pyenv
- INFO: pyenv root: /home/user/.pyenv
- INFO: Using: g:python3_host_prog = "/usr/bin/python"
- WARNING: Your virtualenv is not set up optimally (/usr/bin/python is not in /home/user/.pyenv).
- ADVICE:
- Create a virtualenv specifically for Neovim and use `g:python3_host_prog`. This will avoid the need to install Neovim's Python module in each virtualenv.
- WARNING: $VIRTUAL_ENV exists but appears to be inactive. This could lead to unexpected results.
- ADVICE:
- If you are using Zsh, see: http://vi.stackexchange.com/a/7654
- INFO: Executable: /usr/bin/python
- INFO: Python3 version: 3.6.4
- INFO: python-neovim version: 0.2.1
- OK: Latest python-neovim is installed: 0.2.1
```
Currently writedelay shows the sequence of characters that are sent to
the UI/TUI module. Here nvim has already applied an optimization: when
attempting to put a char in a screen cell, if the same char already was
there with the same attributes, UI output is disabled. When debugging
redrawing it it sometimes more useful to inspect the redraw stream one
step earlier, what region of the screen nvim actually is recomputing
from buffer contents (win_line) and from evaluating statusline
expressions.
Take the popupmenu as an example. When closing the popupmenu (in the
TUI), currently 'writedelay' looks like vim only is redrawing the region
which the pum covered. This is not what happens internally: vim redraws
the entire screen, even if only outputs the changed region.
This commit allows negative values of 'writedelay', which causes a delay
for all redrawn characters, even if the character already was displayed
by the UI before.
Most fonts should have these by now. Both are a significant visual
improvement.
- Vertical connecting bar `│` is used by tmux, pstree, Windows 7 cmd.exe
and nvim-qt.exe.
- Middle dot `·` works on Windows 7 cmd.exe, nvim-qt.exe.
For reference: tmux uses these chars to draw lines: │ ├ ─
`g:loaded_python3_provider` gets set when the autoload file is sourced,
but this might error out, e.g. with deoplete:
[deoplete] Failed to load python3 host. You can try to see what happened by starting nvim with $NVIM_PYTHON_LOG_FILE set and opening the generated log file. Also, the host stderr is available in messages.
[deoplete] function remote#define#FunctionBootstrap[1]..remote#host#Require[10]..provider#pythonx#Require[13]..provider#Poll, line 14
[deoplete] deoplete requires Python3 support("+python3").
[deoplete] deoplete failed to load. Try the :UpdateRemotePlugins command and restart Neovim. See also :checkhealth.
It refers to `:checkhealth` from there explicitly, which would then
(without this patch) say that Python 3 is disabled.
This patch changes the reported info to include that it might have been
disabled due to some error, and keeps on going.
Only remove the directory contents. If the directory itself is removed,
then `sudo make install` creates a root-owned …/doc/ directory. That
breaks the next non-root build.
This was an accident of 0b1904d835.
Note: the following does not work, because it misses renamed help files
(which would no longer be in the build-tree definition)
COMMAND ${CMAKE_COMMAND} -E remove ${BUILDDOCFILES} ${GENERATED_HELP_TAGS}
If `jobstart()` fails, then the subsequent `rpcrequest()` will throw due
to an invalid channel id. This causes `job.stderr` not to exist, so we
throw another exception when trying to dump the job's stderr.
Error detected while processing function remote#define#AutocmdBootstrap[1]..remote#host#Require[10]..provider#pythonx#Require:
line 22:
E716: Key not present in Dictionary: stderr
This obfuscates the actual problem.
On some versions of macOS, pbcopy doesn't work in tmux <2.6
https://superuser.com/q/231130
Fallback to tmux in that case.
Add a healthcheck for this scenario.
Per CMAKE docs, CMAKE_HOST_SYSTEM_VERSION is the result of `uname -r`:
https://cmake.org/cmake/help/v3.4/variable/CMAKE_HOST_SYSTEM_VERSION.html?highlight=uname
A numeric version string for the system. On systems that support
uname, this variable is set to the output of uname -r. On other
systems this is set to major-minor version numbers.
On Windows it is something like "6.1", so it won't match ".*-Microsoft".
Closes#7329
Problem: 'hlsearch' highlighting not removed after incsearch (lacygoill)
Solution: Redraw all windows. Start search at the end of the match. Improve
how CTRL-G works with incremental search. Add tests. (Christian
Brabandt, Hirohito Higashi, haya14busa, closesvim/vim#2267)
https://github.com/vim/vim/commit/f8f8b2eadbaf3090fcfccbab560de5dbd501833d
The argument expansion for :Man depends on the number of arguments given to it
starting at the command itself. But user completion functions always provide the
entire command-line which can include modifier commands like :tab, :vert, etc.
leading to a wrong number of arguments.
Prune all arguments up to :Man.
Fixes#7872.
This should handle most cases where Nvim was invoked as $MANPAGER.
Ultimately the stakes are low: :quit will prompt if there are unsaved
changes.
fix#7873
Error detected while processing function man#open_page[58]..<SNR>54_put_page:
line 8:
E5105: Error while calling lua chunk: /usr/share/nvim/runtime/lua/man.lua:165: Vim(let):E805: Using a Float as a Number
b-r-o-c-k