The primitive C canonicalizer we use to strip out duplicate header
declarations and keep luajit's ffi happy, didn't work properly in this case.
What happened is this (in /usr/include/ctype.h):
__DARWIN_CTYPE_TOP_inline int
isspecial(int _c)
{
return (__istype(_c, _CTYPE_T));
}
Gets preprocessed to something like:
__inline int
isspecial(int _c)
{
return (__istype(_c, _CTYPE_T));
}
On OSX/gcc. The formatter wasn't recognizing this entire function as
something to put on a single line because it naively just checks for
"static" or "inline" for that, but not "__inline".
This error doesn't occur on OSX/clang. Without looking further into it, I
guess that __DARWIN_CTYPE_TOP_inline gets defined to inline on clang, but
__inline on gcc, for some reason.
This helps issue #1572 along.
The second argument to lfs.attributes() serves only to select a specific
part of the normally returned table. It's not a file open flag (e.g.: as for
fopen() in C). Also made the (n)eq checks a bit more idiomatic.
Fixes#1831
Ignoring invalid key sequences simplifies input handling in UIs. The only
downside is having to use "<lt>" everytime a "<" is needed on functional tests.
Ignoring invalid key sequences simplifies input handling in UIs. The only
downside is having to use "<lt>" everytime a "<" is needed on functional tests.
While we're at, using the slightly more portable `command -v` technique
to detect the executable. Also, there's no need to use `io.popen()` if
we aren't going to record the path. Instead, let's use the simpler
`os.execute()` to detect the presence of xclip.
In Lua, all math is floating point. We need to coerce the result of a
division into a integer with the `{get,set}_height` and
`{get,set}_width` window_spec functional tests.
The $GDB env var can be set to run tests under gdbserver. If $VALGRIND is also
set, it will add the --vgdb=yes command-line option to valgrind instead of
starting gdbserver.
See https://github.com/neovim/neovim/issues/1519 for failure report.
Cause : In OSX, /tmp is a symbolic link to /private/tmp, which causes
expected and got results different because of implicit
resolution.
Solution : Resolve path before setting expected value.
Nvim wasn't exiting cleanly in some job tests due to errors.
This can't be noticed until the next commit, which will perform a refactoring to
selectively process K_EVENT, so the `qa!` command executed at the end of each
test blocks forever if there are errors which require the user to press ENTER(in
that state Nvim no longer will process events).
The vim_input function accepts raw terminal input and so is better to emulate
real user, especially because it is not deferred as vim_feedkeys.
Using this function required a number of changes:
- expect() was refactored to use curbuf_contents()
- The vim_eval function in request() was moved to curbuf_contents(). For most
cases this is enough(we only care for synchronizing api calls with user input
when verifying buffer contents).
- <C-@>(NUL) is preprocessed before being passed to replace_termcodes.
- Legacy test 4 had a bug that only became visible when using vim_input, it is
fixed now.
- An extra blank line deletion was required for test 101
The last two items show that vim_feedkeys because it is not 100% equivalent to
receiving terminal input.
