- echo "" does not hang in powershell
- cmd.exe's echo command does not hang.
- job tests default to powershell (WHY?)
- wait 5 seconds for powershell to create an empty file
- powershell is slow
- cannot reliably validate the id returned by jobstart via jobpid, jobstop
- if using cmd.exe, waiting for a second should be enough
- remaining job tests are unreliable in Windows because any build can pass/fail
for same conditions without changes, especially if the error is in stderr
It was added in the parent commit, but ended up not being used. And
I can't think of a case where it will be used: instead we would probably
want to generalize expect_msg_seq() if necessary.
Test_edit_08() depends on special-case handling in has_compl_option()
and redrawing() which are in Vim but are not wanted in Nvim. Using a Lua
test instead of depending on workarounds in the core to make the VimL
test work.
Make HlAttr contain highlighting state for both color modes (cterm and rgb).
This allows us to implement termguicolors completely in the TUI.
Simplify some logic duplicated between ui.c and screen.c. Also avoid
some superfluous highlighting reset events.
The old behavior is probably not justified, for the usual reason:
terminal buffers may have interactive processes, so cursor placement is
arbitrary, therefore tracking it in the jumplist is useless (or worse).
N.B.: per the docstring for `checkpcmark()` it looks like we were
calling `checkpcmark()` and `setpcmark()` in the wrong order.
closes#3723
Lua (not LuaJIT) complains about the "^[[" strings inside the expect,
since it sees them as nested quotes. Change the quoting to [=[ ]=] to
avoid the issue.
Use unique filenames to avoid test conflicts.
Use read_file() instead of io.popen(), to ensures the file is closed.
Use helpers.rmdir(), it is far more robust than lfs.
closes#7911
vim-patch:8.0.0358: invalid memory access in C-indent code
Problem: Invalid memory access in C-indent code.
Solution: Don't go over end of empty line. (Dominique Pelle, closesvim/vim#1492)
60629d6425
vim-patch:8.0.0359: 'number' and 'relativenumber' are not properly tested
Problem: 'number' and 'relativenumber' are not properly tested.
Solution: Add tests, change old style to new style tests. (Ozaki Kiichi,
closesvim/vim#1447)
dc9a081712
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
This reverts commit f7fe3012204169f22412194a78f196ffc72bb8c3.
Fails on QuickBuild because it uses a non-local path.
Need a environment-agnostic solution
Problem: CTRL-G/CTRL-T don't work with incsearch and empty pattern.
Solution: Use the last search pattern. (Christian Brabandt, closesvim/vim#2292)
d048009717
Problem: Incremental search only shows one match.
Solution: When 'incsearch' and and 'hlsearch' are both set highlight all
matches. (haya14busa, closesvim/vim#2198)
2e51d9a097
When tv_get_string_chk returns a non-NULL value, we have a valid string.
Propagating an error state (*len = -1, NULL return) for an empty string
is invalid.
Closes#6554
Problem: The effect of adding "vim/vim#" to 'cinoptions' is not always removed.
(David Briscoe)
Solution: Reset b_ind_hash_comment. (Christian Brabandt, closesvim/vim#1475)
6b64394f34
cb02137dfa had two mistakes, of the same nature: trans_special() must
be invoked with in_string=false unless the parsing context is a VimL
string. replace_termcodes() and input_enqueue() are low-level
mechanisms where VimL strings do not exist.
keymap.c: adjust double-quote case to satisfy keymap_spec.lua
closes#7410
closes#7572closes#7579closes#7628
ASAN report:
==9500==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6040000024c0 at pc 0x00000187d2ca bp 0x7fc3c6e58d10 sp 0x7fc3c6e58d08
READ of size 8 at 0x6040000024c0 thread T1
0 0x187d2c9 in ugrid_put /home/vagrant/neovim/build/../src/nvim/ugrid.c:107:17
1 0x1850adf in tui_put /home/vagrant/neovim/build/../src/nvim/tui/tui.c:1012:10
2 0x18a6ce6 in ui_bridge_put_event /home/vagrant/neovim/build/src/nvim/auto/ui_events_bridge.generated.h:154:3
3 0xa4dcda in multiqueue_process_events /home/vagrant/neovim/build/../src/nvim/event/multiqueue.c:150:7
4 0xa478bf in loop_poll_events /home/vagrant/neovim/build/../src/nvim/event/loop.c:63:3
5 0x185451c in tui_main /home/vagrant/neovim/build/../src/nvim/tui/tui.c:362:12
6 0x18a3080 in ui_thread_run /home/vagrant/neovim/build/../src/nvim/ui_bridge.c:106:3
7 0x7fc3caaac6b9 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76b9)
8 0x7fc3c9ca33dc in clone /build/glibc-bfm8X4/glibc-2.23/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:109
0x6040000024c0 is located 0 bytes to the right of 48-byte region [0x604000002490,0x6040000024c0)
allocated by thread T1 here:
0 0x50e048 in malloc (/home/vagrant/neovim/build/bin/nvim+0x50e048)
1 0xf7ab71 in try_malloc /home/vagrant/neovim/build/../src/nvim/memory.c:87:15
2 0xf7ad99 in xmalloc /home/vagrant/neovim/build/../src/nvim/memory.c:121:15
3 0x187937b in ugrid_resize /home/vagrant/neovim/build/../src/nvim/ugrid.c:32:17
4 0x184be58 in tui_resize /home/vagrant/neovim/build/../src/nvim/tui/tui.c:770:3
5 0x18a3dc8 in ui_bridge_resize_event /home/vagrant/neovim/build/src/nvim/auto/ui_events_bridge.generated.h:4:3
6 0xa4dcda in multiqueue_process_events /home/vagrant/neovim/build/../src/nvim/event/multiqueue.c:150:7
7 0xa478bf in loop_poll_events /home/vagrant/neovim/build/../src/nvim/event/loop.c:63:3
8 0x185451c in tui_main /home/vagrant/neovim/build/../src/nvim/tui/tui.c:362:12
9 0x18a3080 in ui_thread_run /home/vagrant/neovim/build/../src/nvim/ui_bridge.c:106:3
10 0x7fc3caaac6b9 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76b9)
Thread T1 created by T0 here:
0 0x4655ed in __interceptor_pthread_create (/home/vagrant/neovim/build/bin/nvim+0x4655ed)
1 0x1ad87b0 in uv_thread_create /home/vagrant/neovim/.deps/build/src/libuv/src/unix/thread.c:75
2 0x184b9aa in tui_start /home/vagrant/neovim/build/../src/nvim/tui/tui.c:159:10
3 0x188dd4c in ui_builtin_start /home/vagrant/neovim/build/../src/nvim/ui.c:125:3
4 0xe6d399 in main /home/vagrant/neovim/build/../src/nvim/main.c:457:5
5 0x7fc3c9bbc82f in __libc_start_main /build/glibc-bfm8X4/glibc-2.23/csu/../csu/libc-start.c:291
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
Implement nvim_command_output with `execute({cmd},"silent")`.
Behavior changes:
- does not provoke any hit-enter prompt
- no longer prepends a newline char
- does not capture some noise (like the "[New File]" message, see the
change to tabnewentered_spec.lua)
Technically ("bug-for-bug") this a breaking change. But the previous
behavior of nvim_command_output meant that it probably wasn't used for
anything outside of tests.
Also remove the undocumented `v:command_output` variable which was
a hack introduced only for the purposes of nvim_command_output.
closes#7726
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
Reason: test may contain cleanup at the endwhich is needed for GC to work
properly, but is not done if test fails. With collectgarbage() in former
position it would crash when collecting garbage.
provider#node#can_inspect will fail on some systems because it is common
to have old node versions in OS (any Linux OS that has LTS releases)
and CI (Travis, Appveyor).
NODE_PATH can be trivially set with VimL.
Build scripts don't have to set it for the nodejs tests to work.
NODE_PATH is optional to begin with and is used only as a workaround
for the neovim node.js host.
ci: install nodejs 8 in Appveyor, Travis
provider: check node version for debug support
Resolve https://github.com/neovim/neovim/pull/7577#issuecomment-350590592 for Unix.
provider: test if nodejs in ci supports --inspect-brk
nodejs host for neovim requires nodejs 6+ to work properly.
nodejs 6.12+ or 7.6+ is required for debug support via `node --inspect-brk`.
provider: run cli.js of nodejs host directly
npm shims are useless because the user cannot set node to debug mode via
--inspect-brk. This is problematic on Windows which use batchfiles and
shell scripts to compensate for not supporting shebang.
The patch uses `npm root -g` to get the absolute path of the global npm
modules. If that fails, then the user did not install neovim npm package
globally. Use that absolute path to find `neovim/bin/cli.js`, which is
what the npm shim actually runs with node. glob() is for a simple file
check in case bin/ is removed because the npm shims are ignored now.
closes#7429
Problem: after a help window was closed, a window was selected and its
autocommands triggered. After that, restore_snapshot was called and the
focused window changed, confusing the user.
Solution: Add function get_snapshot_focus() that returns the window that
holds the cursor in a snapshot. Use this function in win_close to make
sure the right window is selected before any autocommand is triggered.
filter('v:_null_list, 'v:val') should return v:_null_list and a similar
statement should hold for map.
Changes after review
* Test inserted in legacy test suite has been removed by reverting the commit
adding it.
* Change the fix to tv_copy the argument before returning.
* Readd the two tests on crashes, and modified their expected return value.
* Move the test from 'incorrect behaviour' section to 'correct behaviour section'
* Add analogous tests for v:_null_dict
Always copy list or dictionary to return variable
If the type of input is correct (i.e. either a list or a dictionary), this
should also be returned.
Note: there are three changes to ascii_isident. Reverting first two (in
find_special_key and first in get_special_key_code) normally fails the new test
with empty &isident, but reverting the third does not. Hence adding `>` to
&isident.
Ref vim/vim#2389.
When building with certain GCC versions, a _Float128 type is present
when setting up the ffi for unit tests.
./test/unit/helpers.lua:256: declaration specifier expected near '_Float128' at line 396
/usr/bin/luajit: /usr/share/lua/5.1/busted/runner.lua:99: attempt to concatenate local 'message' (a table value)
stack traceback:
/usr/share/lua/5.1/busted/runner.lua:99: in function 'fn'
/usr/share/lua/5.1/mediator.lua:103: in function 'publish'
/usr/share/lua/5.1/busted/modules/helper_loader.lua:21: in function 'helperLoader'
/usr/share/lua/5.1/busted/runner.lua:147: in function </usr/share/lua/5.1/busted/runner.lua:11>
/usr/bin/busted:3: in main chunk
[C]: at 0x004044a0
CMake Error at /<<PKGBUILDDIR>>/cmake/RunTests.cmake:53 (message):
Running unit tests failed with error: 1.
Since this is being pulled in by a dependency, not directly used by
nvim, just ignore the type.
Closes#7423
Since "builtin" terminfo definitions were implemented (7cbf52db1b),
the decisions made by tui.c and terminfo.c are more relevant. Exposing
that decision in the 'term' option helps with troubleshooting.
Also: remove code that allowed setting t_Co. `:set t_Co=…` has never
worked; the highlight_spec test asserting that nvim_set_option('t_Co')
_does_ work makes no sense, and should not have worked.
vim-patch:fafcf0dd59fd
patch 8.0.1206: no autocmd for entering or leaving the command line
Problem: No autocmd for entering or leaving the command line.
Solution: Add CmdlineEnter and CmdlineLeave.
fafcf0dd59
The flag enables the current local directory set by ":lcd" to be saved
to views which is the current default behaviour. The option can be
removed to disable this behaviour.
closes#7435
vim-patch:8.0.1289
This fixes an apparent difference in behavior between Lua and LuaJIT.
Lua fails to format nil:
test/functional/terminal/tui_spec.lua:381: bad argument #2 to 'format' (string expected, got nil)
Travis disabled IPv6:
[ RUN ] serverstart(), serverstop() parses endpoints correctly: FAIL
...build/neovim/neovim/test/functional/eval/server_spec.lua:83: Expected objects to be the same.
Passed in:
(table) {
[1] = '127.0.0.1:12345' }
Expected:
(table) {
[1] = '127.0.0.1:12345'
*[2] = '::1:12345' }
Change all tests to ensure a server was actually started before
expecting it to be returned from serverlist().
... that does not have that superflous last line.
Also, remove some indeterminism for the freebsd64 tests. Partially,
those were suggested by the tests themselves, while successfull. Some of
them were added after some testing because the lookaround test would
fail on freebsd64 only.
With the old behavior, if a GUI makes a blocking request that requires user
interaction (like nvim_input()), it would not get any screen updates.
The client, not nvim, should decide how to handle notifications during a
pending request. If an rplugin wants to avoid async calls while a sync call is
busy, it likely wants to avoid processing async calls while another async call
also is handled as well.
This may break the expectation of some existing rplugins. For compatibility,
remote/define.vim reimplements the old behavior. Clients can opt-out by
specifying `sync=urgent`.
- Legacy hosts should be updated to use `sync=urgent`. They could add a flag
indicating which async methods are always safe to call and which must wait
until the main loop returns.
- New hosts can expose the full asyncness, they don't need to offer both
behaviors.
ref #6532
ref #1398d83868fe90
