Look for runtime dependencies diff.exe and win32yank.exe (and
recursively for DLL dependencies) and install them with nvim.exe. If a
dependency is missing a warning will be issued.
Also give NVIM_TUI_ENABLE_CURSOR_SHAPE more granularity:
0 = do not change cursor shape
1 = non-blinking ("steady") cursor with mode-sensitive shape
2 = blinking cursor with mode-sensitive shape
Note: blink state is not changed for Konsole, instead user's terminal
preference makes the decision. (Can't do that for xterm-likes, DECSCUSR
forces us to choose blink-state.)
This is a temporary step until the TUI respects 'guicursor'
Ref: https://github.com/neovim/neovim/issues/2583#issuecomment-272988384
"CSI ? 12 l" stops cursor blinking. `unibi_cursor_normal` need only
_show_ the cursor, not make any pronouncement about cursor blinking.
User's terminal setting (or NVIM_TUI_ENABLE_CURSOR_SHAPE) takes
precedence.
Test sometimes fails on AppVeyor (Windows). 300/50=6, but there could be
environment factors that miss the timer interval on the "edges".
timer_start() does not have such a hard requirement.
- Default to powershell.
- Avoid hardcoded "-c".
- Remove ^M character from received lines.
- pending_win32(): clear() is unnecessary and it pollutes the tests.
Closes#3973
Helped-by: Rui Abreu Ferreira <raf-ep@gmx.com>
Problem: Compiler warning for char/char_u conversion. (Tony Mechelynck)
Inefficient code.
Solution: Use more lines to fill with spaces. (Nikolai Pavlov) Add type cast.
16ec3c9be3
Problem: When using ":vimgrep" may end up with duplicate buffers.
Solution: When adding an error list entry pass the buffer number if possible.
015102e91e
When there is a difference in expected vs. actual row count, the user
gets a confusing message about being unable to string concat a nil value
from screen:expect.
This assert makes it clear what the problem is rather than requiring
people to dig through the code of screen:expect to determine what
happened.
Note some bugs were judged to have too ugly a fix to solve, tests to
demonstrate these problems, and the explanation behind not fixing them
are below.
describe('register . problems', function()
before_each(reset)
-- The difficulty here is: The basic requirement is that the text
-- inserted is treated as if it were typed in insert mode. This is why
-- the paste method is to enter insert mode and enter the ". register
-- into readbuf1.
-- We can't add a count into the readbuf here because the insert mode
-- count is implemented with readbuf2 which is checked for characters
-- after readbuf1.
-- Hence, the ".gp command (which adds extra characters into readbuf1
-- to emulate leaving the cursor after the text by moving the cursor
-- after inserting the text) would insert the motion characters into
-- the buffer instead of using them to move after the insert has been
-- done.
-- I could probably get this working properly with a special flag put
-- into start_redo_ins() and set in do_put(), but I think this adds
-- much more complexity than fixing this bug justifies.
pending('should not change the ". register with ".2p', function()
local orig_register = funcs.getreg('.')
feed('2".p')
eq(orig_register, funcs.getreg('.'))
end)
describe("cursor positioning after undo and redo with '.'", function()
before_each(reset)
local function make_cursor_test(macro_string)
return function()
feed(macro_string)
local afterpos = funcs.getcurpos()
local orig_string = curbuf_contents()
feed('u.')
eq(afterpos, funcs.getcurpos())
expect(orig_string)
end
end
-- The difficulty here is: setting the cursor after the end of the
-- pasted text is done by adding a motion command to the
-- stuffbuffer after the insert.
-- Modifying 'redobuff' is done in the code that handles inserting
-- text and moving around.
-- I could add a special case in ins_esc() that checks for a flag
-- set in do_put() to add the motion character to the redo buffer,
-- but I think that is starting to get way too convoluted for the
-- benefit.
pending('should be the same after ".gp and ".gpu.',
make_cursor_test('".gp'))
-- The difficulty here is: putting forwards is implemented by using
-- 'a' instead of 'i' to start insert.
-- Undoing with 'u' an insert that began with 'a' leaves the cursor
-- where the first character was inserted, not where the cursor was
-- when the 'a' was pressed.
-- We account for this the first time by saving the cursor position
-- in do_put(), but this isn't stored in redobuff for a second time
-- around.
-- We can't change how such a fundamental action as undo after
-- inserting with 'a' behaves, we could add in a special case
-- whereby we set a flag in do_put() and read it when entering
-- insert mode but this seems like way too much to fix such a minor
-- bug.
pending('should be the same after ".pu. and ".pu.u.',
make_cursor_test('".pu.'))
end)
end)
Problem: The list_lbr_utf8 test fails if ~/.vim/syntax/c.vim sets
'textwidth' to a non-zero value. (Oyvind A. Holm)
Solution: Add a setup.vim file that sets 'runtimepath' and $HOME to a safe
value. (partly by Christian Brabandt, closesvim/vim#912)
89b10421ca
Problem: When a keymap is active only "(lang)" is displayed. (Ilya
Dogolazky)
Solution: Show the keymap name. (Dmitri Vereshchagin, closesvim/vim#933)
73ac0c4281
Also make setpos("'A", [999, 1, 1, 0]) fail, i.e. return -1 (assuming there is no buffer 999).
Fixes#5713
Background:
`:help setpos()` mentions an argument `"bufnum"` that determines the buffer a mark should be put in.
This argument is respected for uppercase marks, but not for lowercase marks.
This is reasonable (though I personally would like `setpos()` to be able to set marks in other buffers), but the help doesn't mention this anywhere.
It's also strange that attempting to change buffers with `setpos('.', [bufnr('#'), 1, 1, 0])` alerts the user that having a different buffer is an error, while attempting to set a mark with `setpos("'d", [bufnr('#'), 1, 1, 0])` doesn't tell the user that the `"bufnum"` argument is an error.
This was an attempt to enable test/functional/provider/python3_spec.lua
It actually *does* appear to work if we do this:
mingw32-make functionaltest VERBOSE=1 PATH=C:\Python35;C:\Python27;%PATH%
Note that %PATH% *already* has C:\Python35 at its start by then, so
PATH=C:\Python35;C:\Python27;%PATH% is _redundant_.
python3_spec.lua *does* find python3.exe in that case, and succeeds.
But it causes weird failures in unrelated tests:
[----------] Running tests from C:/projects/neovim/test/functional\core\job_partial_spec.lua
[ RUN ] ...rojects/neovim/test/functional\core\job_partial_spec.lua @ 17: jobs with partials works correctly
.\test\functional\helpers.lua:89: Vim(call):E903: Process for command "powershell" could not be spawned
stack traceback:
.\test\functional\helpers.lua:89: in function 'request'
.\test\functional\helpers.lua:147: in function 'nvim_command'
.\test\functional\helpers.lua:344: in function 'source'
...rojects/neovim/test/functional\core\job_partial_spec.lua:18: in function <...rojects/neovim/test/functional\core\job_partial_spec.lua:17>
[ ERROR ] ...rojects/neovim/test/functional\core\job_partial_spec.lua @ 17: jobs with partials works correctly (0.00 ms)
[ RUN ] C:/projects/neovim/test/functional\eval\execute_spec.lua @ 73: execute() does not capture shell-command output
C:/projects/neovim/test/functional\eval\execute_spec.lua:74: Expected objects to be the same.
Passed in:
(string) '
:!echo "foo"
Cannot execute cmd.exe
shell returned -1
'
Expected:
(string) '
:!echo "foo"
'
stack traceback:
C:/projects/neovim/test/functional\eval\execute_spec.lua:74: in function <C:/projects/neovim/test/functional\eval\execute_spec.lua:73>
[ FAILED ] C:/projects/neovim/test/functional\eval\execute_spec.lua @ 73: execute() does not capture shell-command output (15.60 ms)
[ RUN ] C:/projects/neovim/test/functional\ex_cmds\arg_spec.lua @ 11: :argument does not restart :terminal buffer
C:/projects/neovim/test/functional\ex_cmds\arg_spec.lua:18: Expected objects to be the same.
Passed in:
(boolean) false
Expected:
(boolean) true
stack traceback:
C:/projects/neovim/test/functional\ex_cmds\arg_spec.lua:18: in function <C:/projects/neovim/test/functional\ex_cmds\arg_spec.lua:11>
[ FAILED ] C:/projects/neovim/test/functional\ex_cmds\arg_spec.lua @ 11: :argument does not restart :terminal buffer (0.00 ms)
[ RUN ] C:/projects/neovim/test/functional\ex_cmds\edit_spec.lua @ 11: :edit without arguments does not restart :terminal buffer
C:/projects/neovim/test/functional\ex_cmds\edit_spec.lua:16: Expected objects to be the same.
Passed in:
(boolean) false
Expected:
(boolean) true
stack traceback:
C:/projects/neovim/test/functional\ex_cmds\edit_spec.lua:16: in function <C:/projects/neovim/test/functional\ex_cmds\edit_spec.lua:11>
[ FAILED ] C:/projects/neovim/test/functional\ex_cmds\edit_spec.lua @ 11: :edit without arguments does not restart :terminal buffer (15.60 ms)
[ RUN ] ...s/neovim/test/functional\eval\msgpack_functions_spec.lua @ 457: msgpackparse() function msgpackparse(systemlist(...)) does not segfault. #3135
.\test\functional\helpers.lua:89: Failed to evaluate expression
stack traceback:
.\test\functional\helpers.lua:89: in function 'eval'
...s/neovim/test/functional\eval\msgpack_functions_spec.lua:460: in function <...s/neovim/test/functional\eval\msgpack_functions_spec.lua:457>
[ ERROR ] ...s/neovim/test/functional\eval\msgpack_functions_spec.lua @ 457: msgpackparse() function msgpackparse(systemlist(...)) does not segfault. #3135 (15.63 ms)
[ FAILED ] 3 tests, listed below:
[ FAILED ] C:/projects/neovim/test/functional\eval\execute_spec.lua @ 73: execute() does not capture shell-command output
[ FAILED ] C:/projects/neovim/test/functional\ex_cmds\arg_spec.lua @ 11: :argument does not restart :terminal buffer
[ FAILED ] C:/projects/neovim/test/functional\ex_cmds\edit_spec.lua @ 11: :edit without arguments does not restart :terminal buffer
[ ERROR ] 2 errors, listed below:
[ ERROR ] ...rojects/neovim/test/functional\core\job_partial_spec.lua @ 17: jobs with partials works correctly
[ ERROR ] ...s/neovim/test/functional\eval\msgpack_functions_spec.lua @ 457: msgpackparse() function msgpackparse(systemlist(...)) does not segfault. #3135
64 SKIPPED TESTS
3 FAILED TESTS
2 ERRORS
-- Output to stderr:
The system cannot find the path specified.
CMake Error at C:/projects/neovim/cmake/RunTests.cmake:46 (message):
Running functional tests failed with error: 1.
While a job callback is active, it may be invoked again. Since the
data handled by the first invocation of the callback hasn't been marked
as consumed, the subsequent invocation will see the same data.
Reported-by: Daniel Hahler
Patch-by: oni-link
Closes#5889
