[vim/vim] Test fixes for slower systems (#5685)

[James McCoy]

Couple fixes from investigating test failures on hppa, from the thread "Test failure E89 in Test_terminal_special_chars() line 11 (bwipe)".

---

You can view, comment on, or merge this pull request online at:

  https://github.com/vim/vim/pull/5685

Commit Summary

• Test_terminal_special_chars(): Wait for term job to finish
• Test_autocmd_SafeState: Be more tolerant for slow computers

File Changes

• M src/testdir/test_autocmd.vim (6)
• M src/testdir/test_terminal.vim (2)

Patch Links:

• https://github.com/vim/vim/pull/5685.patch
• https://github.com/vim/vim/pull/5685.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

[Bram Moolenaar]

James McCoy wrote:

> Couple fixes from investigating test failures on hppa, from the thread ["Test failure E89 in Test_terminal_special_chars() line 11 (bwipe)"](https://groups.google.com/d/msgid/vim_dev/CAON-T_g8-0XrCq7%2BZ0U8Z-XYP%3D9t9dEzYs-S2G8PCtoXcdg0Hg%40mail.gmail.com).

I already included the change to test_terminal.vim.

I hesitate including the other change. It relaxes what the test is
checking, I'm not sure that is needed.

As with the other test failure, I'm wondering whether RunVimInTerminal()
picks up the right Vim executable.


--
Contrary to popular belief, Unix is user friendly.
It just happens to be selective about who it makes friends with.
-- Dave Parnas

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[James McCoy]

It relaxes what the test is checking, I'm not sure that is needed.

Did you check the example failures I mentioned in the commit? It's a timing issue where many more iterations are able to happen between the sub-vim being told what to do and the parent vim checking the result.

I'm wondering whether RunVimInTerminal() picks up the right Vim executable.

The only vim executable in the chroot is the one created during the build.

[Bram Moolenaar]

James McCoy wrote:

> > It relaxes what the test is checking, I'm not sure that is needed.
>
> Did you check the example failures I mentioned in the commit? It's a
> timing issue where many more iterations are able to happen between the
> sub-vim being told what to do and the parent vim checking the result.

I can understand that g:safe contains a higher count, that should be OK.

g:again containing fewer "x", hmm, I suppose there is no guarantee we
get four.

Having "t" appear more than once should not happen, the timer is only
triggered once. Perhaps the waiting time is too short? 50ms is just a
guess. Only my system it already works with a 10ms wait. Let me make
it 100ms to stay on the safe side.

> > I'm wondering whether RunVimInTerminal() picks up the right Vim executable.
>
> The only vim executable in the chroot is the one created during the build.

OK, that can't be the problem then.

--
Laughing helps. It's like jogging on the inside.

[Bram Moolenaar]

Closed #5685 via 8fb1b47.