[mini.test] Why type_keys uses async nvim_input instead of sync nvim_feedkeys?

[powerman]

My point it, even with some non-zero wait arg any use of type_keys will be a race condition anyway. We're sending keys to a child process to test for their effect, but we don't know how long we should wait until that effect will actually happens.

[echasnovski]

I don't quite remember the details, but I think it was a combination of several things:

• In various tests nvim_input() should to be a closer way to emulate how user presses keys. Specifically because it is non-blocking. With default zero wait each argument's keys just happens instantaneously while arguments are separated by event loop calls.
• I think blocking nature of nvim_feedkeys() was an obstacle for some cases of testing key sequences that block the editor. Like pressing d puts Neovim in Operator-pending mode which awaits user input. But I am not 100% sure here.

We're sending keys to a child process to test for their effect, but we don't know how long we should wait until that effect will actually happens.

Basically I'd say expect that keys themselves are processed right away but if they are meant to trigger async response, then it depends on the nature of that response about how long to wait until it has effect.

[powerman]

Basically I'd say expect that keys themselves are processed right away but if they are meant to trigger async response, then it depends on the nature of that response about how long to wait until it has effect.

Well, I observe something different. All I did is just sent jdd and then read buffer back to assert next line was removed. With wait delay 0-5 test almost always fail (line wasn't deleted yet), with wait delay 100 test always pass. Here is what I did:

child.restart { '--cmd', 'set rtp+=.' }
local lines = { 'Lorem', 'ipsum', 'dolor', 'sit', 'amet' }
child.api.nvim_buf_set_lines(0, 0, -1, true, lines)
child.type_keys('jdd') -- race condition
-- child.api.nvim_feedkeys('jdd', 'tx', false) -- this one works ok
assert.same({ 'Lorem', 'dolor', 'sit', 'amet' }, child.api.nvim_buf_get_lines(0, 0, -1, true))

[echasnovski]

Well, I observe something different. All I did is just sent jdd and then read buffer back to assert next line was removed. With wait delay 0-5 test almost always fail (line wasn't deleted yet), with wait delay 100 test always pass.

I can not reproduce this as a separate test case (with the exception of using MiniTest.expect.equality instead of assert.same()) in any of the following setups:

• Locally on Linux with Neovim 0.8.3, 0.9.4, 0.10.2, v0.11.0-dev-1123+g0eae0bc804.
• On GitHub Actions on the same setups as previous point plus Neovim 0.10.1 on Windows and MacOS.

What OS and Neovim version can you see this behavior? Also, what CPU does the testing machine have?

[powerman]

You right! I've oversimplified the example and this result in issue gone. Sorry!

It turns out this issue happens together with require('lazy').install():wait(). Please try to reproduce it this way:

1. Have lazy installed in usual place.
2. Create this lazy-minit.lua:

local lazypath = vim.fn.stdpath 'data' .. '/lazy/lazy.nvim'
vim.opt.rtp:prepend(lazypath)

require('lazy').setup {
    spec = {
        { 'folke/lazy.nvim', version = '*' },
    },
}
require('lazy').install():wait() -- REMOVING THIS LINE FIXES THE ISSUE WITH child.type_keys RACE

3. Run this test:

local assert = require 'luassert'

local child = require('mini.test').new_child_neovim()
teardown(child.stop)

local function child_lines()
    return child.api.nvim_buf_get_lines(0, 0, -1, true)
end

local lines = { 'Lorem', 'ipsum', 'dolor', 'sit', 'amet' }

before_each(function()
    child.restart { '-u', 'lazy-minit.lua' }
    child.api.nvim_buf_set_lines(0, 0, -1, true, lines)
end)

it('should work', function()
    child.type_keys(16, 'jdd') -- On my system wait=16 is racy 50/50%, wait=10 is almost always fail, wait=100 always succeed
    assert.same({ 'Lorem', 'dolor', 'sit', 'amet' }, child_lines())
end)

[echasnovski]

It turns out this issue happens together with require('lazy').install():wait(). Please try to reproduce it this way:

Sorry, but no. If it works with nvim --clean but doesn't work with some other custom 'init.lua', then it is not an issue with child.type_keys() but an issue with custom 'init.lua'. I'd try first by adding a delay after setting up things in 'lazy-minit.lua'