For debugging failures like:
test/functional/helpers.lua:240: test/functional/ui/screen.lua:898:
bad argument #1 to 'unpack' (table expected, got number)
test/functional/helpers.lua:240: test/functional/ui/screen.lua:708:
attempt to index local 'item' (a number value)
ref #10804
Adapt some tests for OpenBSD:
- scrollback_spec:
- seq(1) is not available on OpenBSD: we'd use jot(1).
- Instead use a (hopefully) portable awk(1) snippet.
- channels_spec
- job_spec
- tui_spec
NB: the `!(flags & SOPT_GLOBAL)` exception is for 'statusline'.
Because `:set statusline=...` sets the global value for _all_ windows,
`:setlocal` is the best we can do there. This is a one-of-a-kind option
that doesn't work like any other option.
- All "chunks" in a paste-stream should form a single undo-block. Side
effect of 7a85792884 was to create an undo-block for each chunk.
- Also: remove old :redraw force logic, irrelevant after 7a85792884.
Otherwise cursor and redraw code for normal and insert mode will not run. The
"tickle" workaround was used for this instead, and can now be removed.
The builtin vim.lua got the name
[string "-- Nvim-Lua stdlib: thevimmodule (:help l..."]
in error messages. Fix it to something reasonable.
REP_NODELAY was added because REP delayed too much. This changes REP to
only add a delay on every 100th line instead.
This helps to cover the additional pulse steps with
out_data_decide_throttle, which would have required to change
REP_NODELAY anyway.
- Introduce TRY_WRAP() until we have an *architectural* solution.
- TODO: bfredl idea: prepare error-handling at "top level" (nv_event).
- nvim_paste(): Revert luaeval() hack (see parent commit).
- With TRY_WRAP() in nvim_put(), 'nomodifiable' error now correctly
"bubbles up".
- nvim_paste(): Marshal through luaeval() instead of nvim_execute_lua()
because the latter seems to hide some errors.
- Handle 'nomodifiable' in `nvim_put()` explicitly.
- Require explicit `false` from `vim.paste()` in order to "cancel",
otherwise assume true ("continue").
- Show error only once per "paste stream".
- Drain remaining chunks until phase=3.
- Lay groundwork for "cancel".
- Constrain semantics of "cancel" to mean "client must stop"; it is
unrelated to presence of error(s).
Workaround this failure:
[ ERROR ] test/functional/terminal/tui_spec.lua @ 192: TUI paste: exactly 64 bytes
test/functional/helpers.lua:403:
retry() attempts: 478
test/functional/terminal/tui_spec.lua:201: Expected objects to be the same.
Passed in:
(table: 0x47cd77e8) {
*[1] = 'zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz endz' }
Expected:
(table: 0x47cd7830) {
*[1] = 'zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz end' }
This happens because `curwin->w_cursor.col` is sometimes decremented at
the end of `do_put`... because the editor is in Normal-mode instead of
the expected Insert-mode.
Caused by "typeahead race" (#10826): there may be queued input in the
main thread not yet processed, thus the editor mode (`State` global)
will be "wrong" during paste. Example: input "i" followed immediately by
a paste sequence:
i<start-paste>...<stop-paste>
^
"i" does not get processed in time, so the editor is in
Normal-mode instead of Insert-mode while handling the paste.
Attempted workarounds:
- vim.api.nvim_feedkeys('','x',false) in vim._paste()
- exec_normal() in tinput_wait_enqueue()
- LOOP_PROCESS_EVENTS(&main_loop,…,0) in tinput_wait_enqueue()
ref #10826
Fixes strange behavior where sometimes the buffer contents of a series
of paste chunks (vim._paste) would be out-of-order.
Now the tui_spec.lua screen-tests are much more reliable. But they still
sometimes fail because of off-by-one cursor (caused by "typeahead race"
resulting in wrong mode; fixed later in this patch-series).
Problem: The a: dict is not immutable as documented.
Solution: Make the a:dict immutable, add a test. (Ozaki Kiichi, Yasuhiro
Matsumoto, closesvim/vim#3929)
31b816042f
Inspired by quickbuild failure, where `g:val` was increased already:
20:07:04,227 INFO - not ok 1164 - timers works with repeat two
20:07:04,227 INFO - # test/functional/eval/timer_spec.lua @ 36
20:07:04,227 INFO - # Failure message: test/functional/eval/timer_spec.lua:38: Expected objects to be the same.
20:07:04,227 INFO - # Passed in:
20:07:04,227 INFO - # (number) 1
20:07:04,227 INFO - # Expected:
20:07:04,227 INFO - # (number) 0
20:07:04,227 INFO - # stack traceback:
20:07:04,227 INFO - # test/functional/eval/timer_spec.lua:38: in function <test/functional/eval/timer_spec.lua:36>
Uses a pattern of `eq()`ing `timer_start` and `g:val` in the same `eval`
call, and decreases timeouts in general.
Improves runtime from ~5s to <2s.
There was a longer timeout for Windows already, but unlike stated in
51d42917f it is not a worst-case, but gets waited for always.
The test is only about "-1" on timeout, so reduce it to this.
Fixes:
16:33:19,309 INFO - not ok 627 - jobs jobwait with timeout argument will return -1 if the wait timed out
16:33:19,309 INFO - # test/functional/core/job_spec.lua @ 707
16:33:19,309 INFO - # Failure message: test/functional/core/job_spec.lua:714: Expected objects to be the same.
16:33:19,309 INFO - # Passed in:
16:33:19,309 INFO - # (table: 0x0db1a3f0) {
16:33:19,309 INFO - # [1] = 'notification'
16:33:19,309 INFO - # [2] = 'wait'
16:33:19,309 INFO - # *[3] = {
16:33:19,309 INFO - # *[1] = {
16:33:19,309 INFO - # *[1] = -1
16:33:19,309 INFO - # [2] = -1 } } }
16:33:19,309 INFO - # Expected:
16:33:19,309 INFO - # (table: 0x0db1a480) {
16:33:19,309 INFO - # [1] = 'notification'
16:33:19,309 INFO - # [2] = 'wait'
16:33:19,309 INFO - # *[3] = {
16:33:19,309 INFO - # *[1] = {
16:33:19,309 INFO - # *[1] = 4
16:33:19,309 INFO - # [2] = -1 } } }
16:33:19,309 INFO - # stack traceback:
16:33:19,309 INFO - # test/functional/core/job_spec.lua:714: in function <test/functional/core/job_spec.lua:707>
Seen on quickbuild:
23:01:01,289 INFO - not ok 1172 - timers can be stopped from the handler
23:01:01,289 INFO - # test/functional/eval/timer_spec.lua @ 154
23:01:01,289 INFO - # Failure message: test/functional/eval/timer_spec.lua:166: Expected objects to be the same.
23:01:01,289 INFO - # Passed in:
23:01:01,289 INFO - # (number) 3
23:01:01,289 INFO - # Expected:
23:01:01,289 INFO - # (number) 0
23:01:01,289 INFO - # stack traceback:
23:01:01,289 INFO - # test/functional/eval/timer_spec.lua:166: in function <test/functional/eval/timer_spec.lua:154>
Log: http://neovim-qb.szakmeister.net/build/24288
Ref: https://github.com/neovim/neovim/pull/10364
Before this commit, when `inccomand` was set to `nosplit`, multi-line
substitutions collapsed the command-line.
This happened because when ex_getln.c:cursorcmd() computed a msg_row, it
was given a cmdline_row one line too high. This happened because
message.c:msg_puts_display() was supposed to decrement cmdline_row but
didn't, because of the `msg_no_more && lines_left == 0` check placed
just before the decrementation part in msg_puts_display's while loop.
Every time msg_puts_display writes a line, it decreases `lines_left` (a
variable used to know how many lines are left for prompts). Since
redrawcommandline() did not reset `lines_left` between calls to
msg_puts_display, every time a character was pressed, `lines_left` was
decremented. This meant that once the user pressed COLUMNS+ROWS numbers
of characters, `lines_left` would reach 0 and prevent msg_row from being
decremented.
It makes sense to fix setting `lines_left` to `cmdline_row` in
`compute_cmdrow` ; after all, computing where the command line row
should be placed is equivalent to computing how many `lines_left` of
output there are left.
Closes#8254.
(<Cmd>0<cr> is not really a no-op, it moves the cursor.)
Attempt to avoid flaky test:
test/functional/ui/cmdline_spec.lua @ 830
Failure message: ./test/functional/ui/screen.lua:579: Row 2 did not match.
Expected:
| |
|*{1:~ }|
|{3: }|
|:012345678901234567890123|
|456789^ |
Actual:
| |
|*{3: }|
|:012345678901234567890123|
|:012345678901234567890123|
|456789^ |
./test/functional/ui/screen.lua:579: in function '_wait'
./test/functional/ui/screen.lua:367: in function 'expect'
test/functional/ui/cmdline_spec.lua:841: in function <test/functional/ui/cmdline_spec.lua:830>
ref https://github.com/neovim/neovim/pull/10171#issuecomment-520134344
ref #10171
Regardless of the comment "Big timeout for ASAN/valgrind" it would use
10s by default already.
This changes it to use `load_adjust`, which itself is only computed on
CI now, and outside of any tests - since it has side effects when being
used the first time!
The failure seen on AppVeyor:
[ RUN ] jobs can get the pid value using getpid: ERR
test\functional\helpers.lua:167:
==============================================================================
got 0 messages (ignored 0), expected 1
stack traceback:
test\functional\helpers.lua:167: in function 'expect_msg_seq'
test/functional\core\job_spec.lua:288: in function <test/functional\core\job_spec.lua:281>
Log: https://ci.appveyor.com/project/neovim/neovim/builds/26537324/job/y1io66fbx399q7h6?fullLog=true#L6554
Fix flaky "shell command :! throttles shell-command output greater than ~10KB:":
[ RUN ] shell command :! throttles shell-command output greater than ~10KB:
warning: Screen changes were received after the expected state. This indicates
indeterminism in the test. Try adding screen:expect(...) (or wait()) between
asynchronous (feed(), nvim_input()) and synchronous API calls.
- Use screen:redraw_debug() to investigate; it may find relevant intermediate
states that should be added to the test to make it more robust.
- If the purpose of the test is to assert state after some user input sent
with feed(), adding screen:expect() before the feed() will help to ensure
the input is sent when Nvim is in a predictable state. This is preferable
to wait(), for being closer to real user interaction.
- wait() can trigger redraws and consequently generate more indeterminism.
Try removing wait().
ERR
test/functional/ui/screen.lua:579: Failed to match any screen lines.
Expected (anywhere): "
%."
Actual:
|XXXXXXXXXX 591 |
|XXXXXXXXXX 592 |
|XXXXXXXXXX 593 |
|XXXXXXXXXX 594 |
| |
| |
|{3:-- TERMINAL --} |
stack traceback:
test/functional/ui/screen.lua:579: in function '_wait'
test/functional/ui/screen.lua:367: in function 'expect'
test/functional/ui/output_spec.lua:63: in function <test/functional/ui/output_spec.lua:53>
Log: https://travis-ci.org/neovim/neovim/jobs/569082705#L5355
(gcc-functionaltest-lua)
The call to plugin_helpers.reset() is redundant with the clear() call
above it. Probably just a copy-paste mistake.
Avoids exit_event race #8813.
Helped-by: Björn Linse <bjorn.linse@gmail.com>
This extra retry() was removed (at my suggestion) in 5b94a2977a, but
it is probably needed: jobwait(…, timeout=0) could return while
channel_process_exit_cb() is still queued (so TermClose event didn't
fire yet).
20:46:21,288 INFO - not ok 547 - TermClose event triggers when fast-exiting terminal job stops
20:46:21,288 INFO - # test/functional/autocmd/termclose_spec.lua @ 20
20:46:21,288 INFO - # Failure message: ./test/functional/helpers.lua:98: Vim:E121: Undefined variable: g:test_termclose
20:46:21,288 INFO - # stack traceback:
20:46:21,288 INFO - # ./test/functional/helpers.lua:98: in function 'eval'
20:46:21,288 INFO - # test/functional/autocmd/termclose_spec.lua:25: in function <test/functional/autocmd/termclose_spec.lua:20>
Instead of deciding provider status in eval_has_provider, move the
decision to the provider Vim scripts.
Previously, provider loading worked as follows:
1. eval_has_provider() verified provider availability by searching for
the provider#providername#Call function and cached this verificaion as a static
variable for some providers
2. providers short-circuited on loading to prevent the definition of the
Call function (with the exception of the node provider that did not)
This commit changes the expected interface between nvim and its
providers to facilitate provider reloading, by splitting the
verification of the provider from the availability of the Call function.
eval_has_provider() now checks for a provider#providername#enabled
variable. It is up to the provider script to set this to 0 or 1
accordingly. eval_call_provider() remains unchanged.
All providers hosting a Call function were updated to respect this.
The clipboard provider now has a Reload function to reload the
provider.
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
For unknown reasons it does not have the trailing space in `:args`
output there anymore:
[ FAILED ] test/functional\ex_cmds\arg_spec.lua @ 11: :argument does not restart :terminal buffer
test/functional\ex_cmds\arg_spec.lua:25: Expected objects to be the same.
Passed in:
(string) '
[term://.//4552:C:\Windows\system32\cmd.exe]'
Expected:
(string) '
[term://.//4552:C:\Windows\system32\cmd.exe] '
stack traceback:
test/functional\ex_cmds\arg_spec.lua:25: in function <test/functional\ex_cmds\arg_spec.lua:11>
The test is not about that though, and this can be made less strict by
using `trim()`. The new test in `test_arglist.vim` for no trailing
newline is OK, and contains trailing spaces. So this is likely due to
the length of it exceeding the column width already.
Problem: ":args" output is hard to read.
Solution: Make columns with the names if the output is more than one line.
5d69da462f
vim-patch:8.0.1740: warning for signed-unsigned incompatibility
Problem: Warning for signed-unsigned incompatibility.
Solution: Change type from "char *" to "char_u *". (John Marriott)
405dadb63e
Removes ported legacy test that was re-added later.
Ref: https://github.com/neovim/neovim/pull/10147#issuecomment-512609513
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
Typically most shell output is the result of non-trivial work, so it
would not blast stdout instantaneously. To more closely simulate that
typical scenario, change `shell-test REP` to wait 1 millisecond between
iterations.
Factor `get_snapshot()` out of `print_snapshot()`, so that callers can
get a table (for use with `expect()`) instead of the string form.
Try to use this to fix indeterminism in `searchhl_spec.lua`.
- Since the screen state is collected by `screen:expect_unchanged()`,
we don't need a deterministic initial state (which would then be
hardcoded into the test). This allows us to check "did anything
change in the last N ms?" rather than "did anything change compared
to a hardcoded screen-state?"
- This may end up fruitless, because `expect_unchanged()` depends on
timing to wait for an initial "current state".
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
Also fix V576: use width specification
> Incorrect format. Consider checking the third actual argument of the
> 'sscanf' function. It's dangerous to use string specifier without width
> specification. Buffer overflow is possible.
- 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.
The interaction between 'winblend' and doublewidth chars in the background
does not look very good. But check no chars get incorrectly placed
at least.
Also check that hidden EndOfBuffer region (from style="minimal") blends
correctly.
- 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.
Note: test doesn't fail on master. I cannot reproduce the glitches with
-u NONE, probably it requires interfering events. But add some coverage
for these checks at least.
ext_message doesn't set msg_col. Add a space and let client deal with
wrapping. When using silent redirect show the unwrapped message form.
Removed check is already part of msg_advance()
Flaky test (osx):
[ FAILED ] ...is/build/neovim/neovim/test/functional/lua/loop_spec.lua @ 23: vim.loop timer
...is/build/neovim/neovim/test/functional/lua/loop_spec.lua:56: Expected objects to be the same.
Passed in:
(number) 0
Expected:
(number) 2
stack traceback:
...is/build/neovim/neovim/test/functional/lua/loop_spec.lua:56: in function <...is/build/neovim/neovim/test/functional/lua/loop_spec.lua:23>
It was bumped from sleeping for 20ms to 50ms in d33aaa0f5f already.
[ ERROR ]...neovim/neovim/test/functional/autocmd/termclose_spec.lua @ TermClose event triggers when fast-exiting terminal job stops
test/functional/helpers.lua:96: Vim(call):E900: Invalid channel id
stack traceback:
test/functional/helpers.lua:96: in function 'request'
test/functional/helpers.lua:254: in function 'command'
...neovim/neovim/test/functional/autocmd/termclose_spec.lua:23: in function <...neovim/neovim/test/functional/autocmd/termclose_spec.lua:20>
Rationale: the purpose of nvim_execute_lua is to simply call lua code with lua
values. If a lua function expects a floating point value, it should be enough
to specify a float as argument to nvim_execute_lua.
However, make sure to preserve the existing roundtripping behavior of
API values when using `vim.api` functions. This is covered by existing
lua/api_spec.lua tests.
* build: update some test dependencies
* luacheck ignores
* BuildLua: add ${BUSTED} to depends for ${BUSTED_LUA}
This is required to rebuild it when busted gets updated.
This matches Vim behavior. From `:help :ls` :
R a terminal buffer with a running job
F a terminal buffer with a finished job
? a terminal buffer without a job: `:terminal NONE`
TODO: implement `:terminal NONE`.
ref #10349
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>
<Paste> is a 3-byte sequence and the beginning one or two bytes can appear at
the very end of the typeahead buffer. When this happens, we were exiting from
`vgetorpeek()` instead of reading more characters to see the complete sequence.
I think this should fix#7994 -- at least partially. Before this change, when I
paste exactly 64 characters into a freshly booted instance, I get what I pasted
plus the literal text "<Paste>" at the end. Nvim also stays in nopaste mode.
The attached test case fails in this manner without the code change.
Fix#7994
* screen: Fix to draw signs with combining characters.
The buffer size for signs can be too small, because the upper length
limit of a sign can be 56 bytes. If combining characters are only two
bytes in size, this reduces to 32 bytes.
* screen: Adjust buffer size to maximal sign column count
There might be an existing job already - maybe due to some other test,
but in this case there was only one failure in the test run.
```
[----------] Running tests from C:/projects/neovim/test/functional\api\proc_spec.lua
[ RUN ] api nvim_get_proc_children returns child process ids: ERR
test\functional\helpers.lua:392:
retry() attempts: 450
C:/projects/neovim/test/functional\api\proc_spec.lua:22: Expected objects to be the same.
Passed in:
(number) 2
Expected:
(number) 1
stack traceback:
test\functional\helpers.lua:392: in function 'retry'
C:/projects/neovim/test/functional\api\proc_spec.lua:21: in function <C:/projects/neovim/test/functional\api\proc_spec.lua:17>
```
https://ci.appveyor.com/project/neovim/neovim/builds/25461215/job/8ns204v6091iy9rs?fullLog=true#L2672
* ci: AppVeyor: set GCOV_ERROR_FILE
This prevents the warnings/errors to be spilled into test results,
causing them to fail them, e.g.:
[ FAILED ] C:/projects/neovim/test/functional\core\main_spec.lua @ 97: Command-line option -s errors out when trying to use nonexistent file with -s
C:/projects/neovim/test/functional\core\main_spec.lua:98: Expected objects to be the same.
Passed in:
(string) 'Cannot open for reading: "Xtest-functional-core-main-s.nonexistent": no such file or directory
profiling:C:\projects\neovim\build/src/nvim/CMakeFiles/nvim.dir/buffer.c.gcda:Data file mismatch - some data files may have been concurrently updated without locking support
'
Expected:
(string) 'Cannot open for reading: "Xtest-functional-core-main-s.nonexistent": no such file or directory
'
stack traceback:
C:/projects/neovim/test/functional\core\main_spec.lua:98: in function <C:/projects/neovim/test/functional\core\main_spec.lua:97>
For reference, the locking appears to have been reworked for gcc 9.1 [1].
1: https://github.com/gcc-mirror/gcc/commit/56621355b
helpers.clear: keep GCOV_ERROR_FILE in environment
* ci: AppVeyor: remove MINGW_64 config (used with cov now)
Also:
- run MINGW_64-gcov first, and with PRs, since it provides coverage.
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
Problem: When we changed startup to wait for the TUI (like a remote UI),
we forgot to set os/input.c:global_fd. That used to be done by
input_start().
Solution: Initialize os/input.c:global_fd before initializing libtermkey
(termkey_new_abstract) so that tui_get_stty_erase() and
friends can inspect the correct fd.
fixes#10134close#10174
Problem: Sign message not translated and inconsistent spacing.
Solution: Add _() for translation. Add a space. (Ken Takata) Also use
MSG_BUF_LEN instead of BUFSIZ.
d730c8e297
Problem: Placing signs can be complicated.
Solution: Add functions for defining and placing signs. Introduce a group
name to avoid different plugins using the same signs. (Yegappan
Lakshmanan, closesvim/vim#3652)
162b71479b
Unfortunately we cannot indiscriminately replace xfree() with
XFREE_CLEAR(), because comparing pointers after freeing them is a common
pattern. Example in `tv_list_remove_items()`:
xfree(li);
if (li == item2) {
break;
}
Instead we can do it selectively/explicitly.
ref #1375
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').
This is where "pure functions" can live, which can be shared by Nvim and
test logic which may not have a running Nvim instance available.
If in the future we use Nvim itself as the Lua engine for tests, then
these functions could be moved directly onto the `vim` Lua module.
closes#6580
Automatically include all "global helper" util functions in the
unit.helpers and functional.helpers and modules. So tests don't need to
expicitly do:
local global_helpers = require('test.helpers')
Previously, ordinary redraws were missing from terminal mode. Instead,
there was an async callback that invoked update_screen() on terminal
data regardless of mode (as if :redraw! was invoked by a timer).
This created some issues:
- async changes to an unrelated ordinary buffer were not always redrawn in
terminal mode
- screen cursor position was not properly updated in terminal mode (partial
fix, will be properly fixed in a follow up PR)
- ad-hoc logic was needed for interaction with special states such as
inccommand or horizontal wildmenu.
Instead redraw terminal mode just like any other state. This disables forced
redraws in cmdline mode, which were inconisent which async changes to
normal buffers (which are not redrawn in cmdline mode).
- redraw! in an invisible buffer rendered the screen unusable.
- storing the autocmd window handle and using it in API function could lead
to crashes. Unregister the handle when the window is not active.
closes#9136
- Treat empty {rhs} like <Nop>
- getchar.c: Pull "repl. MapArg termcodes" into func
The "preprocessing code" surrounding the replace_termcodes calls needs
to invoke replace_termcodes, and also check if RHS is equal to "<Nop>".
To reduce code duplication, factor this out into a helper function.
Also add an rhs_is_noop flag to MapArguments; buf_do_map_explicit
expects an empty {rhs} string for "<Nop>", but also needs to distinguish
that from something like ":map lhs<cr>" where no {rhs} was provided.
- getchar.c: Use allocated buffer for rhs in MapArgs
Since the MAXMAPLEN limit does not apply to the RHS of a mapping (or
else an RHS that calls a really long autoload function from a plugin
would be incorrectly rejected as being too long), use an allocated
buffer for RHS rather than a static buffer of length MAXMAPLEN + 1.
- Mappings LHS and RHS can contain literal space characters, newlines, etc.
- getchar.c: replace_termcodes in str_to_mapargs
It makes sense to do this; str_to_mapargs is, intuitively, supposed to
take a "raw" command string and parse it into a totally "do_map-ready"
struct.
- api/vim.c: Update lhs, rhs len after replace_termcodes
Fixes a bug in which replace_termcodes changes the length of lhs or rhs,
but the later search through the mappings/abbreviations hashtables
still uses the old length value. This would cause the search to fail
erroneously and throw 'E31: No such mapping' errors or 'E24: No such
abbreviation' errors.
- getchar: Create new map_arguments struct
So that a string of map arguments can be parsed into a more useful, more
portable data structure.
- getchar.c: Add buf_do_map function
Exactly the same as the old do_map, but replace the hardcoded references
to the global `buf_T* curbuf` with a function parameter so that we can
invoke it from nvim_buf_set_keymap.
- Remove gettext calls in do_map error handling
Before now, Nvim always degrades UI capabilities to the lowest-common
denominator. For example, if any connected UI has `ext_messages=false`
then `ext_messages=true` requested by any other connected UI is ignored.
Now `nvim_ui_attach()` supports `override=true`, which flips the
behavior: if any UI requests an `ext_*` UI capability then the
capability is enabled (and the legacy behavior is disabled).
Legacy UIs will be broken while a `override=true` UI is connected, but
it's useful for debugging: you can type into the TUI and observe the UI
events from another connected (UI) client. And the legacy UI will
"recover" after the `override=true` UI disconnects.
Example using pynvim:
>>> n.ui_attach(2048, 2048, rgb=True, override=True, ext_multigrid=True, ext_messages=True, ext_popupmenu=True)
>>> while True: n.next_message();
Problem: No simple way to label quickfix entries.
Solution: Add the "module" item, to be used instead of the file name for
display purposes. (Martin Szamotulski)
d76ce85266
On Windows we store non-config data in "$XDG_DATA_HOME/nvim-data". But
the "…/site" items in 'runtimepath' did not correctly point to that
location, they used "…/nvim/site".
Fix the init logic to use "…/nvim-data/site".
closes#9910
Callers can instead specify `args_rm={'--headless'}`.
TODO: should `nvim_argv` have "--headless" by default? Need to inspect
some uses of spawn(nvim_argv) ...
Problem: Using `:stopinsert` while in normal mode in a terminal buffer
prevents neovim from entering insert mode.
Solution: Move `stop_insert_mode = false` from terminal_check to
terminal_enter to be consistent with edit.c, as suggested by bfredl in
#9889.
Closes https://github.com/neovim/neovim/issues/9889.
- Allow floating windows of width 1. #9846
- For a new floating window the size must be specified. Later on we
might try to calculate a reasonable size by buffer contents
- Remember the configured size of a window, just like its position.
- Make get_config and set_config more consistent. Handle relative='' properly in set_config.
get_config doesn't return keys that don't make sense for a non-floating window.
- Don't use width=0 for non-changed width, just omit the key.
vim-patch:8.0.0714: when a timer causes a command line redraw " goes missing
Problem: When a timer causes a command line redraw the " that is displayed
for CTRL-R goes missing.
Solution: Remember an extra character to display.
a92522fbf3
vim-patch:8.0.0720: unfinished mapping not displayed when running timer
Problem: Unfinished mapping not displayed when running timer.
Solution: Also use the extra_char while waiting for a mapping and digraph.
(closesvim/vim#1844)
6a77d2667eclose#9835
Using `:wincmd j` and friends doesn't make much sense to a floating window. For
convenience though, any direction will simply change to the previous window.
Make sure the previous window is valid, not the current window, and not another
floating window. Change to the first window (which is never a floating window)
otherwise.
validate_cursor() is called regularly, but only for the current window.
When changing the buffer for a non-current window, we need to invoke it
in the context of that window.
CA_COMMAND_BUSY in nv_event() was carried over from Vim nv_cursorhold()
(ref: e5165bae11). It prevents :startinsert from working during a RPC
call, so remove it.
Helped-by: glacambre <me@r4>
closes#7254
Problem: Calling :stopinsert from RPC while in terminal-mode does not
go back to normal-mode.
Solution: Implement a check() handler for state_enter(), adapted from
insert_check().
Fix#7807
Problem: Extending sign and foldcolumn below the text is confusing.
Solution: Let the sign and foldcolumn stop at the last text line, just like
the line number column. Also stop the command line window leader.
(Christian Brabandt)
8ee4c01b8c
Closes https://github.com/neovim/neovim/issues/9613
- input: recognize <kEqual>, <kComma>
- terminal.c: If we need to support function key, a change must be made
in libvtermkey. Currently, it emulates strictly VT220 terminal, and
returning numeric value in 'normal' mode is the expected behaviour.
closes#9810
- K_KORIGIN instead of K_KCENTER: This name is similar to what is used
by xev. Alternative could be K_KBEGIN as hinted here:
https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-PC-Style-Function-Keys
But I find Begin and Home too similar, and it might induced some
confusion. The naming looked related to some old keyboard
configuration.
- keymap.c: alias KPPeriod to kDel instead of kPoint.
This might seems weird, but this is actually the behaviour that should
be expected. libtermkey produces "KPPeriod" when num lock is off. To
fix this would need to change this name in termkey.
closes#9780closes#9793
closes#990closes#9295
- Support for multiple auto-adjusted sign columns.
With this change, having more than one sign on a line, and with the
'auto' setting on 'signcolumn', extra columns will shown automatically
to accomodate all the existing signs.
For example, suppose we have this view:
5147 }
5148
5149 return sign->typenr;
5150 }
5151 }
5152 return 0;
5153 }
5154
We have GitGutter installed, so it tells us about modified lines that
are not commmited. So let's change line 5152:
5147 }
5148
5149 return sign->typenr;
5150 }
5151 }
~ 5152 return 0;
5153 }
5154
Now we add a mark over line 5152 using 'ma' in normal mode:
5147 }
5148
5149 return sign->typenr;
5150 }
5151 }
a ~ 5152 return 0;
5153 }
5154
Previously, Vim/Nvim would have picked only one of the signs,
because there was no support for having multiple signs in a line.
- Remove signs from deleted lines.
Suppose we have highlights on a group of lines and we delete them:
+ 6 use std::ops::Deref;
--+ 7 use std::borrow::Cow;
--+ 8 use std::io::{Cursor};
9 use proc_macro2::TokenStream;
10 use syn::export::ToTokens;
--+ 11 use std::io::Write;
>> 12 use std::ops::Deref;
Without this change, these signs will momentarily accumulate in
the sign column until the plugins wake up to refresh them.
+ --+ --+ --+ >> 6
Discussion: It may be better to extend the API a bit and allow this
to happen for only certain types of signs. For example, VIM marks
and vim-gitgutter removal signs may want to be presreved, unlike
line additions and linter highlights.
- 'signcolumn': support 'auto:NUM' and 'yes:NUM' settings
- sort signs according to id, from lowest to highest. If you have
git-gutter, vim-signature, and ALE, it would appear in this order:
git-gutter - vim-signature - ALE.
- recalculate size before screen update
- If no space for all signs, prefer the higher ids (while keeping the
rendering order from low to high).
- Prevent duplicate signs. Duplicate signs were invisible to the user,
before using our extended non-standard signcolumn settings.
- multi signcols: fix bug related to wrapped lines.
In wrapped lines, the wrapped parts of a line did not include the extra
columns if they existed. The result was a misdrawing of the wrapped
parts. Fix the issue by:
1. initializing the signcol counter to 0 when we are on a wrap boundary
2. allowing for the draw of spaces in that case.
Nvim doesn't expect a window-changing command on an created-window event.
autocmd WinNew * wincmd p
help help
- A snapshot for window 1000 is created.
- The window is split and the cursor changes to the new window 1001.
- The autocmd kicks in and switches back to 1000.
- The help buffer is opened.
- On closing the help window 1000, it tries to go back to the snapshotted window
which is... 1000.
- wp1000->w_buffer == NULL
- w_buffer is used by check_cursor()
- 🧨 -> 💥
Fixes https://github.com/neovim/neovim/issues/9773
- Lua test correctly fails when 8.1.0849 is reverted.
- 8.1.1001 bug does not manifest in Neovim.
vim-patch:8.1.0849: cursorline highlight is not always updated
Problem: Cursorline highlight is not always updated.
Solution: Set w_last_cursorline when redrawing. Fix resetting cursor flags
when using the popup menu.
c07ff5c60a
vim-patch:8.1.1001: Visual area not correct when using 'cursorline'
Problem: Visual area not correct when using 'cursorline'.
Solution: Update w_last_cursorline also in Visual mode. (Hirohito Higashi,
closesvim/vim#4086)
8156ed3755
bisected to f5d5da3917
Other test steps:
nvim -u NORC
:terminal tree / " Produces lots of output
:edit somefile.txt
:vsplit
:vsplit
<c-w>l
<c-w>l
<c-w>h
<c-w>p
