| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| |
|
|
| |
ref 773bdd41ec19
|
| |
|
|
|
| |
We already do this for _invalid_ async requests #9300.
Now we also do it for failed invocation of valid requests.
|
| |\ |
|
| | | |
|
| |/
|
|
|
| |
close #9515
ref #9280
|
| |
|
|
| |
make Screen explicitly tied to its session
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ref #9280
Introduce the `vim.compat` module, to help environments with system Lua
5.2+ run the build/tests. Include the module implicitly in all tests.
ref #8677
legacy `vim` module:
beep
buffer
command
dict
eval
firstline
lastline
line
list
open
type
window
|
| |
|
|
|
| |
Make the code run both on Lua 5.1 (which is the default for Neovim, and
is what LuaJIT provides) and Lua 5.2+.
|
| |
|
|
|
| |
Previously, nvim sent a response with invalid request id (UINT64_MAX).
In functionaltests, catch unexpected error notifications in after_each().
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
- window_split_tab_spec.lua: Put cursor at bottom of :terminal buffer so
that it follows output.
- inccommand_spec.lua: Increase timeout to allow 2nd retry.
- Timer tests are less reliable on Travis CI macOS 10.12/10.13.
ref #6829
ref e39dade80b02
ref de13113dc16e
ref https://github.com/neovim/neovim/pull/9095#issuecomment-429603452
> We don't guarantee that a X ms timer is triggered during Y ms sleep
> for any X<Y, though I would expect the load to be really bad for this
> to happen with X=10ms, Y=40ms.
|
| | |
|
| |
|
|
|
|
| |
Give embeders a chance to set up nvim, by processing a request before
startup. This allows an external UI to show messages and prompts from
--cmd and buffer loading (e.g. swap files)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
closes #8362
Vim's code calls `call_shell` directly from `get_system_output_as_rettv`
whereas in Nvim this function has been rewritten to not call `call_shell` but to call
`os_system` via `do_os_system`, losing the support for profiling and verbose.
Changing the code to call `call_shell` from `get_system_output_as_rettv`
seems to be too complicated to be worth it on the current version of the
code. So this commit duplicates the relevant code.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Avoid a hot loop in retry(), there's no need to retry more than 50/s.
Also use luv.sleep() to implement sleep() instead of spinning the
event-loop, so events are not silently discarded.
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| |
| | |
cmd.exe (shell) is faster and more reliable than powershell (.NET frontend).
It's best for short and basic tests that don't require non-trivial scripting.
cmd.exe doesn't support sleep so use powershell's Start-Sleep as substitute.
|
| | |
| |
| | |
other cleanup, ref #8245
|
| |/ |
|
| |
|
|
|
|
| |
Infinite timeout results in hangs which waste time. If some test needs
longer than 10s to wait for a message, it should specify the timeout
explicitly.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
It was added in the parent commit, but ended up not being used. And
I can't think of a case where it will be used: instead we would probably
want to generalize expect_msg_seq() if necessary.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
job_spec.lua on AppVeyor (Windows) often fails like this:
FAILED ] C:/projects/neovim/test/functional\core\job_spec.lua @ 72: jobs changes to given `cwd` directory
C:/projects/neovim/test/functional\core\job_spec.lua:81: Expected objects to be the same.
Passed in:
(table) {
[1] = 'notification'
[2] = 'stdout'
*[3] = {
[1] = 0
*[2] = {
[1] = 'C:\projects\neovim\Xtest-tmpdir\nvimmSjq1S\0' } } }
Expected:
(table) {
[1] = 'notification'
[2] = 'stdout'
*[3] = {
[1] = 0
*[2] = {
[1] = 'C:\projects\neovim\Xtest-tmpdir\nvimmSjq1S\0'
*[2] = '' } } }
stack traceback:
Message chunking is non-deterministic, so we need to try different
variants.
|
| |
|
|
|
| |
fix #7909
fix #7910
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement nvim_command_output with `execute({cmd},"silent")`.
Behavior changes:
- does not provoke any hit-enter prompt
- no longer prepends a newline char
- does not capture some noise (like the "[New File]" message, see the
change to tabnewentered_spec.lua)
Technically ("bug-for-bug") this a breaking change. But the previous
behavior of nvim_command_output meant that it probably wasn't used for
anything outside of tests.
Also remove the undocumented `v:command_output` variable which was
a hack introduced only for the purposes of nvim_command_output.
closes #7726
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ci: install nodejs 8 in Appveyor, Travis
provider: check node version for debug support
Resolve https://github.com/neovim/neovim/pull/7577#issuecomment-350590592 for Unix.
provider: test if nodejs in ci supports --inspect-brk
nodejs host for neovim requires nodejs 6+ to work properly.
nodejs 6.12+ or 7.6+ is required for debug support via `node --inspect-brk`.
provider: run cli.js of nodejs host directly
npm shims are useless because the user cannot set node to debug mode via
--inspect-brk. This is problematic on Windows which use batchfiles and
shell scripts to compensate for not supporting shebang.
The patch uses `npm root -g` to get the absolute path of the global npm
modules. If that fails, then the user did not install neovim npm package
globally. Use that absolute path to find `neovim/bin/cli.js`, which is
what the npm shim actually runs with node. glob() is for a simple file
check in case bin/ is removed because the npm shims are ignored now.
|
| | |
|
| |
|
|
|
| |
libuv caches the results of uv.now() until the next loop tick. If a test
does not spin the libuv event loop, retry() enters an infinite cycle.
|
| |
|
|
|
|
|
|
|
|
| |
Since "builtin" terminfo definitions were implemented (7cbf52db1bdf),
the decisions made by tui.c and terminfo.c are more relevant. Exposing
that decision in the 'term' option helps with troubleshooting.
Also: remove code that allowed setting t_Co. `:set t_Co=…` has never
worked; the highlight_spec test asserting that nvim_set_option('t_Co')
_does_ work makes no sense, and should not have worked.
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | |
| |
| | |
Fixes #6957
|
| |/ |
|
| |\
| |
| | |
lua: Add paths from &runtimepath to package.path and package.cpath
|
| | | |
|
| | | |
|
| | | |
|
| |/
|
|
| |
Helped-By: oni-link <knil.ino@gmail.com>
|
| | |
|
| |
|
|
| |
Test correctly fail for oneline ruby, python and python3.
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Asynchronous API functions are served immediately, which means pending
input could change the state of Nvim shortly after an async API function
result is returned.
nvim_get_mode() is different:
- If RPCs are known to be blocked, it responds immediately (without
flushing the input/event queue)
- else it is handled just-in-time before waiting for input, after
pending input was processed. This makes the result more reliable
(but not perfect).
Internally this is handled as a special case, but _semantically_ nothing
has changed: API users never know when input flushes, so this internal
special-case doesn't violate that. As far as API users are concerned,
nvim_get_mode() is just another asynchronous API function.
In all cases nvim_get_mode() never blocks for more than the time it
takes to flush the input/event queue (~µs).
Note: This doesn't address #6166; nvim_get_mode() will provoke #6166 if
e.g. `d` is operator-pending.
Closes #6159
|
| | |\ |
|
| | |/ |
|
