Problem: When user tries to exit with CTRL-C message is confusing.
Solution: Only mention ":qa!" when there is a changed buffer. (closesvim/vim#4163)
a84a3dd663
vim-patch:8.1.1052: test for CTRL-C message sometimes fails
Problem: test for CTRL-C message sometimes fails
Solution: Make sure there are no changed buffers.
553e5a5c56
vim-patch:8.1.1053: warning for missing return statement
Problem: Warning for missing return statement. (Dominique Pelle)
Solution: Add return statement.
d6c3f1fa2b
Windows: In order for jobstart(['foo']), system(['foo']) to find
"foo.cmd", we must replace "foo" with "foo.cmd" before sending `argv` to
process_spawn().
Rationale: jobstart([…]), system([…]) "executable" semantics should be
consistent with the VimL executable() function.
fix#9569
related: #10554
For "backwards" duration, reltimefloat() should return negative value
like its counterpart reltimestr().
ref bab24a88ab
ref 06af88cd72
ref #10521fix#10452
It would previously fail with `set shell=sh` (no slash).
For the test itself we can just use a non-existing (fake) shell, because
it is only about the verbose output.
Ref: https://github.com/neovim/neovim/issues/9330
- reltimestr(): Produce negative value by comparing the unsigned
proftime_T value to INT64_MAX.
https://github.com/neovim/neovim/issues/10452#issuecomment-511155132
1. The interfaces of nearly all platforms return uint64_t. INT64_MAX is
only half of that.
2. Low-level interfaces like this typically define that there is no
fixed starting point. The only guarantees are that it's (a)
monotonically increasing at a rate that (b) matches real time.
ref 06af88cd72fix#10452
* Fix problem that 1byte extra memory was allocated in is_executable_in_path
* Revert "Revert "tests: executable_spec: enable pending test #10443" (#10454)"
This reverts commit 13fbeda0e5.
- Move __gcov_flush to process_spawn, for more reliable coverage
tracking of subprocesses
- Travis: use GCOV_ERROR_FILE
- codecov: use "-X fix" to skip "fixing" uploaded coverage data; it
should be handled by codecov's backend instead.
- AppVeyor: no $PATH mangling, which breaks with the improved coverage tracking
due to missing .dll in PATH.
Seen on Travis (osx):
[ RUN ] timers can be stopped from the handler: FAIL
.../build/neovim/neovim/test/functional/eval/timer_spec.lua:167: Expected objects to be the same.
Passed in:
(number) 2
Expected:
(number) 3
stack traceback:
.../build/neovim/neovim/test/functional/eval/timer_spec.lua:167: in function <.../build/neovim/neovim/test/functional/eval/timer_spec.lua:153>
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.
