2 files changed, 6 insertions, 6 deletions
diff --git a/test/functional/ui/popupmenu_spec.lua b/test/functional/ui/popupmenu_spec.lua
index c44e59cfd3..d521e3cd25 100644
--- a/test/functional/ui/popupmenu_spec.lua
+++ b/test/functional/ui/popupmenu_spec.lua
@@ -2324,7 +2324,7 @@ describe('builtin popupmenu', function()
   it('is closed by :stopinsert from timer #12976', function()
     screen:try_resize(32,14)
     command([[call setline(1, ['hello', 'hullo', 'heeee', ''])]])
-    feed('Gah<C-N>')
+    feed('Gah<c-x><c-n>')
     screen:expect([[
       hello                           |
       hullo                           |
diff --git a/test/functional/ui/screen.lua b/test/functional/ui/screen.lua
index 61f19c3794..a5af898652 100644
--- a/test/functional/ui/screen.lua
+++ b/test/functional/ui/screen.lua
@@ -576,16 +576,16 @@ to the test if they make sense.
     print([[
 
 warning: Screen changes were received after the expected state. This indicates
-indeterminism in the test. Try adding screen:expect(...) (or wait()) between
-asynchronous (feed(), nvim_input()) and synchronous API calls.
+indeterminism in the test. Try adding screen:expect(...) (or poke_eventloop())
+between asynchronous (feed(), nvim_input()) and synchronous API calls.
   - Use screen:redraw_debug() to investigate; it may find relevant intermediate
     states that should be added to the test to make it more robust.
   - If the purpose of the test is to assert state after some user input sent
     with feed(), adding screen:expect() before the feed() will help to ensure
     the input is sent when Nvim is in a predictable state. This is preferable
-    to wait(), for being closer to real user interaction.
-  - wait() can trigger redraws and consequently generate more indeterminism.
-    Try removing wait().
+    to poke_eventloop(), for being closer to real user interaction.
+  - poke_eventloop() can trigger redraws and thus generate more indeterminism.
+    Try removing poke_eventloop().
       ]])
     did_warn = true
   end