redir_write():
- This is a "batch" operation which was not yet covered by
start_batch_changes()
adjust_clipboard_name():
- msg() and friends during :redir will, of course, cause redir_write()
to try to capture that message, which causes recursion.
- EMSG() here is trouble: if it interrupts :redir it is a mess.
Rather than deal with the mess, show a non-error message.
closes#7182closes#7184closes#7183
ref #6048
ref #7032
This allows users who have per-project Ruby versions (e.g. with `rvm`)
to pin to a particular gem installation.
For example: `let g:ruby_host_prog = 'rvm system do neovim-ruby-host'`
Fix the following issues according to rubocop:
runtime/autoload/provider/script_host.rb:2:11: C: Prefer single-quoted strings when you don't need string interpolation or special symbols.
require "neovim/ruby_provider"
^^^^^^^^^^^^^^^^^^^^^^
runtime/autoload/provider/script_host.rb:5:5: C: Prefer single-quoted strings when you don't need string interpolation or special symbols.
"Your neovim RubyGem is missing or out of date. " +
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
runtime/autoload/provider/script_host.rb:5:55: C: Use \ instead of + or << to concatenate those strings.
"Your neovim RubyGem is missing or out of date. " +
runtime/autoload/provider/script_host.rb:6:5: C: Prefer single-quoted strings when you don't need string interpolation or special symbols.
"Install the latest version using `gem install neovim`."
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This commit assumes Ruby 2.0.0+.
The exists('g:loaded_foo') convention is rather common, and may be
relied upon in some cases. It's also very unlikely that a user or plugin
has any reason to set g:loaded_foo to zero, so the principle of least
surprise can be brushed aside here.
https://github.com/neovim/neovim/issues/6107#issuecomment-279532143
This option simplifies the configuration options:
1) `g:python{,3}_host_prog` is not set.
Neovim tries its best to find a suitable interpreter. This means calling
exepath(), potentially multiple times, and a system('python -c ...') with
the first found interpreter, to get the Python version.
2) `g:python{,3}_host_prog` is set.
Avoids everything of the above. No safety checks, no training wheels. Fast
host startup time!
Never throw an error when provider/clipboard.vim is sourced for the first time.
Save the error instead and expose it via `provider#clipboard#Error()`, mimicking
provider/python.vim.
This avoids the issue of nvim started daemons causing mountpoints to be
unmountable. This is currently the only place in runtime/ where this
calling convention occurred.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
This also checks the major/min version only for expected return codes.
With pyenv, you might get the following (return code 127):
pyenv: python3.4: command not found
The `python3.4' command exists in these Python versions:
3.4.3
3.4.3/envs/tmp-3.4.3-eElS6Y
tmp-3.4.3-eElS6Y
`RedirectStream` is used to redirect `stdout` and `stderr`, but are
missing certain I/O methods available on other file-like objects.
This causes external plugins (like `colorama`) to crash.
Inheriting from `io.IOBase` adds an abstract implementation of these
methods, which will at least keep the python code running.
Fixes#4045
"python -c" returns 1 in case of an error. Use a return code of 2 if
the Neovim module is not found to distinguish these cases.
Verify the interpreter version before checking for an installed Neovim
module. Show a new error message if the Python interpreter version
is below the minimum required version.
Always use "pkgutil" to determine if the Neovim module is installed.
In contrast to "importlib", which was used for Python 3,
"pkgutil.find_loader" is available for all Python versions [1,2].
"pkgutil.find_loader" internally uses "importlib" for Python >= 3.3 [2].
Also, the previously used "importlib.find_loader" is only available
since Python 3.3 (so checking the major Python version was not enough)
and deprecated since Python 3.4 [3].
Finally, conditioning on the major version in Vimscript was incorrect,
as checking the Neovim module for a certain Python major version does
not mean that the tested interpreters are actually of that version.
For example, we test the "python" executable, which is Python 2 on
Ubuntu and Python 3 on Arch Linux.
[1] https://docs.python.org/2/library/pkgutil.html#pkgutil.find_loader
[2] https://docs.python.org/3/library/pkgutil.html#pkgutil.find_loader
[3] https://docs.python.org/3/library/importlib.html#importlib.find_loader
Before, running Nvim in a directory containing a Python module `neovim`,
or one that is imported by it or a plugin, will load that module and not
the system one. So Nvim might be tricked into running arbitrary scripts
from the current working directory.
Fixes#1665Fixes#2530
The path hook used to load the module already in the `find_module` hook.
This caused different behaviour between Python 2.7 and 3.3, where the
former would call the `VimModuleLoader`, while Python 3.3 appears to
short-circuited this (because the module was loaded already).
This patch will now only find the module, but not load it in the
`find_module` hook.
