This might be required on (slower) CI.
[ RUN ] timers doesn't mess up the cmdline: ERR
test/functional/ui/screen.lua:562: expected intermediate screen state before final screen state
stack traceback:
test/functional/ui/screen.lua:562: in function '_wait'
test/functional/ui/screen.lua:366: in function 'expect'
.../build/neovim/neovim/test/functional/eval/timer_spec.lua:221: in function <.../build/neovim/neovim/test/functional/eval/timer_spec.lua:199>
Ref: https://travis-ci.org/neovim/neovim/jobs/544974506#L3861
The test.functional.helpers and test.unit.helpers modules now include
all of the public functions from test.helpers, so there is no need to
separately require('test.helpers').
Note: the test fails on non-Windows CI (Travis linux, Quickbuild bsd):
even on master before the env.c changes in this patch-series.
Maybe the unix part of printenv-test.c needs to be revisited.
Signed-off-by: Justin M. Keyes <justinkz@gmail.com>
It's reported that the Windows widechar variants do automatically
convert from the current codepage to UTF16, which is very helpful. So
the "widechar" impls are a good direction. But libuv v1.12 does that
for us, so the next commit will use that instead.
ref #8398
ref #9267
- window_split_tab_spec.lua: Put cursor at bottom of :terminal buffer so
that it follows output.
- inccommand_spec.lua: Increase timeout to allow 2nd retry.
- Timer tests are less reliable on Travis CI macOS 10.12/10.13.
ref #6829
ref e39dade80b
ref de13113dc1
ref https://github.com/neovim/neovim/pull/9095#issuecomment-429603452
> We don't guarantee that a X ms timer is triggered during Y ms sleep
> for any X<Y, though I would expect the load to be really bad for this
> to happen with X=10ms, Y=40ms.
Test is unreliable on macOS 10.13. The lower-bound isn't central to the
purpose of the test, so just relax it.
ref https://github.com/neovim/neovim/pull/9095#issuecomment-429603452
> We don't guarantee that a X ms timer is triggered during Y ms sleep
> for any X<Y, though I would expect the load to be really bad for this
> to happen with X=10ms, Y=40ms.
related: #6829
Avoid clearing the screen in most situations. NOT_VALID should be
equivalent to CLEAR unless some external force messed up the terminal,
for these situations <c-l> and :mode will still clear the screen.
Also eliminate some obsolete code in screen.c, that dealt with that in
vim drawing window 1 can mess up window 2, but this never happens in
nvim.
But what about slow terminals? There is two common meanings in which
a terminal is said to be "slow":
Most commonly (and in the sense of vim:s nottyfast) it means low
bandwidth for sending bytes from nvim to the terminal. If the screen is
very similar before and after the update_screen(CLEAR) this change
should reduce bandwidth. If the screen is quite different, but there is
no new regions of contiguous whitespace, clearing doesn't reduce
bandwidth significantly. If the new screen contains a lot of whitespace,
it will depend of if vsplits are used or not: as long as there is no
vsplits, ce is used to cheaply clear the rest of the line, so
full-screen clear is not needed to reduce bandwith. However a left
vsplit currently needs to be padded with whitespace all the way to the
separator. It is possible ec (clear N chars) can be used to reduce
bandwidth here if this is a problem. (All of this assumes that one
doesn't set Normal guibg=... on a non-BCE terminal, if you do you are
doomed regardless of this change).
Slow can also mean that drawing pixels on the screen is slow. E-ink
screens is a recent example. Avoiding clearing and redrawing the
unchanged part of the screen will always improve performance in these
cases.
closes#8362
Vim's code calls `call_shell` directly from `get_system_output_as_rettv`
whereas in Nvim this function has been rewritten to not call `call_shell` but to call
`os_system` via `do_os_system`, losing the support for profiling and verbose.
Changing the code to call `call_shell` from `get_system_output_as_rettv`
seems to be too complicated to be worth it on the current version of the
code. So this commit duplicates the relevant code.
Problem: For some people the hint about quitting is not sufficient.
Solution: Put <Enter> separately. Also use ":qa!" to get out even when
there are changes.
28a8193e31
- Return VimL errors instead of generic errors for:
- nvim_call_function
- nvim_call_dict_function
- Fix tests which were silently broken before this change.
This violates #6150 where we agreed not to translate API errors. But
that can be fixed later.
I failed to deduce why analyzer thinks E882 may not be triggered, though
conditions for triggering it are strange: it would trigger E882 only in the
single case “function returned non-number”. Cases “function thrown exception”,
or “built-in sorter encountered error” will neither yield E882 nor stop
sort()/uniq().
Note though that searching test code revealed that neither E702 nor E882 are not
tested anywhere.
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
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
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
