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
If parse_shape_opt() is done before user config, the TUI may cause
unwanted changes to the terminal cursor which cannot later be undone
(see #4396).
fix#10750
Problem: Test listed as flaky should no longer be flaky.
Solution: Remove Test_popup_and_window_resize from the list of flaky tests.
(Daniel Hahler, closevim/vim#4807)
9570aacdb8
Problem: Test_popup_and_window_resize() does not always pass.
Solution: Do not use $VIMPROG, pass the Vim executable in the vimcmd file.
(Ozaki Kiichi, closesvim/vim#2186)
631820536e
vim-patch:8.0.1526: no test using a screen dump yet
Problem: No test using a screen dump yet.
Solution: Add a test for C syntax highlighting. Add helper functions.
da65058a9c
NOTE: uses modified `GetVimProg()` (which is used with skipped tests only
(mostly because of `!has('terminal')`)).
Vim uses a 'vimcmd' file, while Nvim uses `$NVIM_TEST_ARGX` environment
variables.
Ref: https://github.com/vim/vim/pull/4806
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.
- Re-enable Test_BufLeave_Wipe. 66f5e5c7d7
This is my (probably-wrong) application of Zyx's suggestion in #9163:
> free_buffer_stuff() already removes changedtick. It is better to
> make `free_options` a flag variable and avoid calling
> buf_init_changedtick() based on some flag there: current workflow
> looks weird as it first removes `b:changedtick`, then re-adds it
> by calling buf_init_changedtick(), then remove again.
> Also based on my understanding it looks logical to not remove
> `b:changedtick`, but to *replace* it with something allocated if
> needed based on examining reference count before calling
> `unref_var_dict`. Because now you have key disappearing from
> dictionary for no good reason.
Patch-By: Nikolai Aleksandrovich Pavlov <kp-pav@yandex.ru>
Problem: Crash when wiping out a buffer after using getbufinfo().
(Yegappan Lakshmanan)
Solution: Remove b:changedtick from the buffer variables.
(Note: The test changes in vim-patch:8.0.1193 were already included.)
- Windows: `set FOO=` deletes environment variable FOO, and there is no
way to set empty string expect by calling the API.
- Vim-compatible: `:let $FOO=""` deletes the environment variable.
- See also Test_WindowsHome().
ref: https://github.com/neovim/neovim/pull/10657#issuecomment-516368089
Problem: Tests do not run or are not reliable on some systems.
Solution: Use "findstr" instead of "grep" on MS-Windows. Clear
PROMPT_COMMAND in the terminal test. Delete temp file. Wait for
output after executing a debug command. (Yegappan Lakshmanan,
closesvim/vim#4479)
ddd3308782
Ignored changes to testdir/test_terminal.vim.
Problem: In screen.c grid_char_needs_redraw clang warns
that grid->chars could be NULL
Solution: Suggested by bfredl. Add explicit check
grid->chars != NULL in grid_put_linebuf
similar to grid_puts_len
(<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
`len` is used with `list_append_string` later, and should reflect the
length of `word` (i.e. 0 when not setting word / breaking above).
Ref: neovim/neovim#9782 (comment)
Daniel Hahler