When rbenv is used for managing Ruby installations, just checking for an
executable called "neovim-ruby-host" is not enough. It has to be run as well.
If it does not return 0, then neovim-ruby-host is merely a shim for another Ruby
installation.
$ rbenv versions
2.5.0
* 2.5.1 (set by /Users/mhi/.rbenv/version)
$ rbenv whence neovim-ruby-host
2.5.0
$ which neovim-ruby-host
/Users/mhi/.rbenv/shims/neovim-ruby-host
$ neovim-ruby-host
rbenv: neovim-ruby-host: command not found
The `neovim-ruby-host' command exists in these Ruby versions:
2.5.0
$ echo $?
127
Additionally, the detection logic was moved from provider#ruby#Detect() to
s:detect(), because the former is run in the sandbox which forbids calling
system().
Problem: There is no way to notice that the quickfix window contents has
changed.
Solution: Increment b:changedtick when updating the quickfix window.
(Yegappan Lakshmanan)
a8788f4d0b
Problem: Minor issues related to quickfix.
Solution: Set the proper return status for all cases in setqflist() and at
test cases for this. Move the "adding" flag outside of
FEAT_WINDOWS. Minor update to the setqflist() help text. (Yegappan
Lakshmanan)
86f100dc09
This would need to get `expand`ed to not become empty, and is being
handled by s:check_bin already.
`s:check_bin` will also complain about e.g.
"~/.pyenv/versions/3.6.6/bin/python" not being executable, but that
reflects that the host will fail to start with it.
Fixes#8778
Problem: The script to check translations fails if there is more than one
NL in one line.
Solution: Count the number of NL characters. Make count() accept a string.
9966b21a57
Problem: The :global command does not work recursively, which makes it
difficult to execute a command on a line where one pattern matches
and another does not match. (Miles Cranmer)
Solution: Allow for recursion if it is for only one line. (closesvim/vim#1760)
f84b122a99
* vim-patch:8.0.0474: the client-server feature is not tested
Problem: The client-server feature is not tested.
Solution: Add a test.
15bf76d40b
* vim-patch:8.0.0475: not enough testing for the client-server feature
Problem: Not enough testing for the client-server feature.
Solution: Add more tests. Add the remote_startserver() function. Fix that
a locally evaluated expression uses function-local variables.
7416f3e73a
* vim-patch:8.0.0492: a failing client-server request can make Vim hang
Problem: A failing client-server request can make Vim hang.
Solution: Add a timeout argument to functions that wait.
81b9d0bd5c
Include src/nvim/testdir/test_clientserver.vim changes from
patches 8.0.0477, 8.0.0479.
* vim-patch:8.0.0633: the client-server test is still a bit flaky
Problem: The client-server test is still a bit flaky.
Solution: Wait a bit for the GUI to start. Check that the version number
can be obtained.
60964f6874
Include src/nvim/testdir/test_clientserver.vim changes
from patches 8.0.0507, 8.0.0511.
* vim-patch:8.0.1251: invalid expressin passed to WaitFor()
Problem: Invalid expressin passed to WaitFor().
Solution: Check if the variable exists.
d97fbf171e
closes#7383closes#7715
This implements the compromise described in #7383:
* low-priority CursorLine if foreground is not set
* high-priority ("same as Vim" priority) CursorLine if foreground is set
ref d1874ab282
ref 56eda2aa17
Compare `$VIRTUAL_ENV` to `python_bin`.
This is necessary when `g:python_host_prog` is set to an absolute path,
and looking up `pyname` in `$PATH` yields another result.
This changes Ex mode (Q, -e) to work like Vim's "improved Ex mode"
(gQ, -E). That brings some small behavior differences, but should not
impact most Ex scripts (unless, for example, they depend on mappings
being disabled--but that can be solved for -e by skipping user config).
Before this change:
* the screen test hangs.
After this change:
* Q acts like gQ.
* -e/-es differs from -E/-Es only in its treatment of stdin.
This moves towards potentially removing getexmodeline().
(HINT: That does NOT mean "removing Ex mode", it means removing the
Vi-compatible Ex mode, which differs from Vim's "improved Ex mode" only
in some minor details (e.g. mappings are disabled).)
ref #1089 :-)~
Problem: When calling setpos() with a buffer argument it often is ignored.
(Matthew Malcomson)
Solution: Make the buffer argument work for all marks local to a buffer.
(neovim vim/vim#5713) Add more tests.
f13e00b2cf
Fixes 2 failing tests in startup_spec.lua.
The Windows-only `--literal` option complicates support of "stdin-as-text
+ file-args" (#7679). Could work around it, but it's not worth
the trouble:
- users have a reasonable (and englightening) alternative: nvim +"n *"
- "always literal" is more consistent/predictable
- avoids platform-specific special-case
Unrelated changes:
- Replace fileno(stdxx) with STDXX_FILENO for consistency (not motivated
by any observed technical reason).
Problem: Character classes are not well tested. They can differ between
platforms.
Solution: Add tests. In the documentation make clear which classes depend
on what library function. Only use :cntrl: and :graph: for ASCII.
(Kazunobu Kuriyama, Dominique Pelle, closesvim/vim#1560)
Update the documentation.
0c078fc7db
Problem: MS-Windows users are confused about default mappings.
Solution: Don't map keys in the console where they don't work. Add a choice
in the installer to use MS-Windows key bindings or not. (Christian
Brabandt, Ken Takata, closesvim/vim#2093)
c3fdf7f80b
Problem: When using the tiny version trying to load the matchit plugin
gives an error. On MS-Windows some default mappings fail.
Solution: Add a check if the command used is available. (Christian Brabandt)
8cc2a9c062
Problem: No autocmd triggered in Insert mode with visible popup menu.
Solution: Add TextChangedP. (Prabir Shrestha, Christian Brabandt,
closesvim/vim#2372, closesvim/vim#1691)
Fix that the TextChanged autocommands are not always triggered
when sourcing a script.
5a09343719
OpenBSD's man returns all candidates when searching with -w instead of
the first one it finds. So this patch takes the first one if multiple
entries are found.
closes#8372closes#8341
After this change we never release blocks from memory (in practice it
never happened because the memory limits are never reached). Let the OS
take care of that.
---
On today's systems the 'maxmem' and 'maxmemtot' values are huge (4+ GB)
so the limits are never reached in practice, but Vim wastes a lot of
time checking if the limit was reached.
If the limit is reached Vim starts saving pieces of the swap file that were in
memory to the disk. Said in a different way: Vim implements its own
memory-paging mechanism. This is unnecessary and inefficient since the
operating system already has virtual memory and will swap to the disk if
programs start using too much memory.
This change does...
1. Reduce the number of config options and need for documentation.
2. Make the code more efficient as we don't have to keep track of memory
usage nor check if the memory limits were reached to start swapping
to disk every time we need memory for buffers.
3. Simplify the code. Once memfile.c is simple enough it could be
replaced by actual operating system memory mapping (mmap,
MemoryViewOfFile...). This change does not prevent Vim to recover
changes from swap files since the swapping code is never triggered
with the huge limits set by default.
Remove "" from sys.path (typically the first entry), which could cause
e.g. "logging" to be added from the current directory.
This gets done already for loading the host in
runtime/autoload/provider/pythonx.vim.
ref #6725
fsync() is very slow on some systems. And since the parent commit, Nvim
is smarter about flushing files at certain times (e.g. CursorHold),
regardless of whether 'fsync' is enabled. So it's less risky to disable
'fsync'.
Profiling showed slow (2-4s) :write and :quit caused by fsync():
:quit
shada_write_file(NULL, false);
:write + fsync
0 0x00007f72da567b2d in fsync () at ../sysdeps/unix/syscall-template.S:84
1 0x0000000000638970 in uv__fs_fsync (req=<optimized out>) at /home/vagrant/neovim/.deps/build/src/libuv/src/unix/fs.c:150
2 uv__fs_work (w=<optimized out>) at /home/vagrant/neovim/.deps/build/src/libuv/src/unix/fs.c:953
3 0x0000000000639a70 in uv_fs_fsync (loop=<optimized out>, req=<optimized out>, file=41, cb=0x7f72da567b2d <fsync+45>)
at /home/vagrant/neovim/.deps/build/src/libuv/src/unix/fs.c:1094
4 0x0000000000573694 in os_fsync (fd=41) at ../src/nvim/os/fs.c:631
5 0x00000000004ec9dc in buf_write (buf=<optimized out>, fname=<optimized out>, sfname=<optimized out>, start=1, end=1997, eap=0x7fffc864c570,
append=<optimized out>, forceit=<optimized out>, reset_changed=<optimized out>, filtering=<optimized out>) at ../src/nvim/fileio.c:3387
6 0x00000000004b44ff in do_write (eap=0x7fffc864c570) at ../src/nvim/ex_cmds.c:1745
...
:write + nofsync
0 0x00007f72da567b2d in fsync () at ../sysdeps/unix/syscall-template.S:84
1 0x0000000000638970 in uv__fs_fsync (req=<optimized out>) at /home/vagrant/neovim/.deps/build/src/libuv/src/unix/fs.c:150
2 uv__fs_work (w=<optimized out>) at /home/vagrant/neovim/.deps/build/src/libuv/src/unix/fs.c:953
3 0x0000000000639a70 in uv_fs_fsync (loop=<optimized out>, req=<optimized out>, file=36, cb=0x7f72da567b2d <fsync+45>)
at /home/vagrant/neovim/.deps/build/src/libuv/src/unix/fs.c:1094
4 0x0000000000573694 in os_fsync (fd=36) at ../src/nvim/os/fs.c:631
5 0x0000000000528f5a in mf_sync (mfp=0x7f72d8968d00, flags=5) at ../src/nvim/memfile.c:466
6 0x000000000052d569 in ml_preserve (buf=0x7f72d890f000, message=0) at ../src/nvim/memline.c:1659
7 0x00000000004ebadf in buf_write (buf=<optimized out>, fname=<optimized out>, sfname=<optimized out>, start=1, end=1997, eap=0x7fffc864c570,
append=<optimized out>, forceit=<optimized out>, reset_changed=<optimized out>, filtering=<optimized out>) at ../src/nvim/fileio.c:3071
8 0x00000000004b44ff in do_write (eap=0x7fffc864c570) at ../src/nvim/ex_cmds.c:1745
...
children_kill_cb() is racey. One obvious problem is that
process_close_handles() is *queued* by on_process_exit(), so when
children_kill_cb() is invoked, the dead process might still be in the
`loop->children` list. If the OS already reclaimed the dead PID, Nvim
may try to SIGKILL it.
Avoid that by checking `proc->status`.
Vim doesn't have this problem because it doesn't attempt to kill
processes that ignored SIGTERM after a timeout.
closes#8269
Problem: Cannot detect Bazel BUILD files on some systems.
Solution: Check for BUILD after script checks. (Issue vim/vim#1340)
39170e2d97
vim-patch:8.0.1283: test 86 fails under ASAN
Problem: Loading file type detection slows down startup.
Solution: Move functions to an autoload script.
851ee6c3da
---
vim-patch:8.0.0635
Problem: When 'ignorecase' is set script detection is inaccurate.
Solution: Enforce matching case for text. (closes#1753)
closes#7698
Wrapping a command in double-quotes allows cmd.exe to safely dequote the
entire command as if the user entered the entire command in an
interactive prompt. This reduces the need to escape nested and uneven
double quotes.
The `/s` flag of cmd.exe makes the behaviour more reliable:
:set shellcmdflag=/s\ /c
Before this patch, cmd.exe cannot use cygwin echo.exe (as opposed to
cmd.exe `echo` builtin) even if it is wrapped in double quotes.
Example:
:: internal echo
> cmd /s /c " echo foo\:bar" "
foo\:bar"
:: cygwin echo.exe
> cmd /s /c " "echo" foo\:bar" "
foo:bar
Update vim_diff.txt with :lmap differences, update documentation on
'keymap', and add tests.
The tests added are to demonstrate the behaviour specified in the
documentation of :loadkeymap.
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.
Problem: The conf filetype detection is done before ftdetect scripts from
packages that are added later.
Solution: Add the FALLBACK argument to :setfiletype. (closesvim/vim#1679,
closesvim/vim#1693)
3e54569b17
Problem: Third item of synconcealed() changes too often. (Dominique Pelle)
Solution: Reset the sequence number at the start of each line.
cc0750dc6ecloses#7589
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)
f8f8b2eadb
Problem: Incremental search only shows one match.
Solution: When 'incsearch' and and 'hlsearch' are both set highlight all
matches. (haya14busa, closesvim/vim#2198)
2e51d9a097
vim-patch:8.0.0431: 'cinoptions' cannot set indent for extern block
Problem: 'cinoptions' cannot set indent for extern block.
Solution: Add the "E" flag in 'cinoptions'. (Hirohito Higashi)
7720ba8599
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
vim-patch:8.0.0151
Problem: To pass buffer content to system() and systemlist() one has to
first create a string or list.
Solution: Allow passing a buffer number. (LemonBoy,
closesvim/vim#1240)
12c4492dd3
vim-patch:8.0.0153
Problem: system() test fails on MS-Windows.
Solution: Deal when extra space and CR.
9d9c356517
vim-patch:8.0.0154
Problem: system() test fails on OS/X.
Solution: Deal with leading spaces.
31f19ce0a0
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
Until now, the default `:filetype ...` setup was skipped if the user
config touched `:filetype` in any way (including implicitly via `:syntax
on`). No one needs that, and it's very confusing.
Instead, proceed with `:filetype ... on` unless the user explicitly
called `:filetype ... off`.
closes#7765
TERM=konsole-256color is recognized by ncurses.
TERM=konsole-xterm might be more clever, but should not be necessary
(for Nvim at least), we already special-case Konsole in various places.
We may need to clean up some areas that currently assume Konsole always
"pretends xterm" (`TERM=xterm-256color`), though I didn't find any such
cases.
ref #6403
ref https://github.com/neovim/neovim/issues/6403#issuecomment-348713346
