It turns out that Busted started cleaning the environment in 2.0rc5 as a
result of Olivine-Labs/busted#62. This, in turn, caused the ffi module
to be reloaded for each spec file, and LuaJIT doesn't appreciate it.
The net effect is an assertion error in LuaJIT.
By using the --helper feature of Busted, we can pre-load some modules
ahead of Busted and prevent it from reloading them--making LuaJIT happy
again.
This is necessary for newer versions of Busted, otherwise assert will be
nil and the tests will die.
Note: this does not mean the tests now work with the latest Busted.
There are still several issues preventing that from happening.
- Removed term.c, term.h and term_defs.h
- Tests for T_* values were removed. screen.c was simplified as a
consequence(the best strategy for drawing is implemented in the UI layer)
- Redraw functions now call ui.c functions directly. Updates are flushed with
`ui_flush()`
- Removed all termcap options(they now return empty strings for compatibility)
- &term/&ttybuiltin options return a constant value(nvim)
- &t_Co is still available, but it mirrors t_colors directly
- Remove cursor tracking from screen.c and the `screen_start` function. Now the
UI is expected to maintain cursor state across any call, and reset it when
resized.
- Remove unused code
- The syntax `gui=` is invalid when setting properties of highlight group.
- Wait for the initial "-- More --" prompt before continuing. Required to avoid
a race condition
Some screen tests such as system/ctrl+c(viml_system_spec.lua) can take some time
to respond(default kill timeout is 2 seconds for an interrupted job) and fail
when running under a slow environment such as travis.
The `system` function is never executed with these tests because the ctrl+c is
queued with the input string that calls it(The `process_interrupts` function
will destroy all previous input when a ctrl+c is found).
The systemlist test currently calls the `echo` command which can potentially
complete before being interrupted, causing random test failures.
Use `yes | xargs` instead. A `yes` invocation that is not piped through `xargs`
can produce a huge amount of lines in a very short time, leading memory
starvation when the result is being converted into a list. `xargs` ensures only
one line of output will be produced while allowing interrupt to be tested.
`job_send` is non-blocking and can potentially fail due to the following
`job_stop` call. Since we can't reliably verify that the "exit" event is only
sent after the "stdout" event, mark the test as pending and fix after we can
get a notification about `job_send` status.
The test was hoping to not find a tags file, but didn't actively guard
against it. In my case, I had a tags file present which was causing
different output to be generated. To fix this, let's set the tags
option to look for an unlikely filename.
