The "technically correct" interpretation is to execute the first line
that is seen (and this is what happens on middle-click paste in Vim).
^M is only intended to "defuse" the newline, so the user can review it.
The parent commit changed the behavior to insert <Space> between lines,
but that's a higher-risk change: it is arguably possible that some user
*wants* the literal ^M chars when e.g. assigning to a register:
:let @a='<C-R>b'
To avoid that risk, keep the old behavior and only omit the last ^M.
This makes `yy:<C-R>0` nicer at no cost.
^M isn't any more "correct" than space: the "technically correct"
interpretation is to execute the first line that is seen (and this is
what happens on middle-click paste in Vim). ^M is only intended to
defuse the newline, so that the user can review the command. We can do
that with a space instead, and then the command can be executed without
having to fix it up first.
1. When calling writefile(list, fname, []) do not show error message twice.
2. Do not allow file name to be overwritten for writefile([1], 2).
3. Do not show “Can’t open file with an empty name” error after error like
“using Float as a String” when type of the second argument is not correct.
4. Do not give multiple error messages and still continue for code like
`writefile(["test", [], [], [], "tset"])`.
Note that to fix 4. ideally I need tv_check_str_or_nr which is currently present
in two PRs: #6114 and #5119. I would want to avoid copying this function into
a yet another PR.
Ref vim/vim#1476.
- Do not exclude any directories from `find` search, remove dumps before tests
instead.
- Install `apport` on travis so that linux tests should produce core dumps
(based on information from travis-ci/travis-ci#3754, not sure whether it still
applies).
- Check cores in lua so that one has an idea which test is failing exactly. Do
this only 10% of time on linux because traversing the file system is slow.
Unit tests are still not touched, though it is what `app` argument in
`check_cores` is for.
TODO? consider using `find`, it may be faster. Consider retiring `os.execute`,
dealing with escaping is bad.
- Add support for TEST_FILE to the `oldtest` target, for consistency
with the busted/lua tests.
Caveat: with the busted/lua tests TEST_FILE takes a full path, whereas
for `oldtest` it must be "test_foo.res".
- Add support for NVIM_PRG, again so that all test-related targets are
consistent.
- Use consistent name for NVIM_PRG. But still need to support NVIM_PROG
for QuickBuild CI.
Note: The `oldtest` target is driven by the top-level Makefile, because
it requires a TTY. CMake 3.2 added a USES_TERMINAL flag to
add_custom_target(). But we support CMake 2.8...
add_custom_target(oldtest
COMMAND make clean
COMMAND make NVIM_PRG=$<TARGET_FILE:nvim> $ENV{MAKEOVERRIDES}
DEPENDS nvim
WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}/src/nvim/testdir"
USES_TERMINAL true
)
patch 8.0.0280: problem setting multi-byte environment var on MS-Windows
Problem: On MS-Windows setting an environment variable with multi-byte
strings does not work well.
Solution: Use wputenv when possible. (Taro Muraoka, Ken Takata)
7c23d1d9d9cc
This was a workaround from long ago, but it doesn't seem to be needed
anymore. And it breaks the $PATH on the Windows build (AppVeyor CI).
After this change python3 (and 2) is correctly detected on AppVeyor CI.
References #5946
This allows executables to be found by :!, system(), and executable() if
they live next to ("sibling" to) nvim.exe. This is what gvim on Windows
does, and also matches the behavior of Win32 SearchPath().
c4a249a736/src/os_win32.c (L354-L370)
When test/functional/eval/system_spec.lua is run on its own,
helpers.os_name() was being called before a session had been created.
This caused that describe block to fail.
Turning printargs_path into a function delays the call of
helpers.os_name() until the test is being run, which ensures a session
is available.
