tui: rework deferred-termcodes implementation

[justinmk]

Try another approach to defer the termcodes. Seems less janky, but still
not perfect. The timer approach (ew) ed92ece eliminates the startup jank.

ref #7664
ref #7649
ref #7664
ref 27f9b1c

---

QB failure with the non-timer approach (6b51c72 ), seems to cause a SIGABRT (134):

17:08:50,472 INFO  - not ok 2405 - tui with non-tty file descriptors can handle pipes as stdout and stderr
17:08:50,472 INFO  - # test/functional/terminal/tui_spec.lua @ 191
17:08:50,472 INFO  - # Failure message: ./test/functional/ui/screen.lua:302: Row 1 did not match.
17:08:50,472 INFO  - # Expected:
17:08:50,472 INFO  - # |*:w testF |
17:08:50,472 INFO  - # |:q |
17:08:50,472 INFO  - # |abc |
17:08:50,472 INFO  - # | |
17:08:50,472 INFO  - # |[Process exited 0]{1: } |
17:08:50,472 INFO  - # | |
17:08:50,472 INFO  - # |{3:-- TERMINAL --} |
17:08:50,472 INFO  - # Actual:
17:08:50,472 INFO  - # |*/root/neovim/pull-requests-automated/build/Release|
17:08:50,472 INFO  - # |/bin/nvim -u NONE -i NONE --cmd 'set noswapfile no|
17:08:50,472 INFO  - # |showcmd noruler' --cmd 'normal iabc' > /dev/null 2|
17:08:50,472 INFO  - # |>&1 |
17:08:50,472 INFO  - # | |
17:08:50,472 INFO  - # |[Process exited 134]{1: } |
17:08:50,472 INFO  - # |{3:-- TERMINAL --} |
17:08:50,472 INFO  - #
17:08:50,472 INFO  - # To print the expect() call that would assert the current screen state, use
17:08:50,472 INFO  - # screen:snapshot_util(). In case of non-deterministic failures, use
17:08:50,472 INFO  - # screen:redraw_debug() to show all intermediate screen states.
17:08:50,472 INFO  - # stack traceback:
17:08:50,472 INFO  - #     ./test/functional/ui/screen.lua:302: in function 'wait'
17:08:50,472 INFO  - #     ./test/functional/ui/screen.lua:216: in function 'expect'
17:08:50,472 INFO  - #     test/functional/terminal/tui_spec.lua:195: in function <test/functional/terminal/tui_spec.lua:191>

[mox-mox]

I tried it. This version takes considerable time until the callbacks are triggered (feels like half a second or maybe a second).

Enough time in fact to switch windows. Then, vim triggers some events and tells my window manager that vim is open and that it should switch to vim mode. Suddenly, my browser window is focussed with my window manager in vim mode and I'm confused.

Would it be possible to defer sending the request only if term=tmux?
Still, thank you for all that time and effort to try to find a solution that fits everyone.

[justinmk]

@mox-mox #7729 should work much better.

[mox-mox]

Yes, this is better and solves the problem for most use cases.
I guess, I'll just have to remember not to switch windows immediately after starting nvim.

[justinmk]

Why? Did you try it? If 100ms still causes the problem then the problem is impossible the avoid...

[mox-mox]

Of course I tested it.
I think 100ms is ok. It is quite difficult to do something so fast after launching vim.

Longer explanation:
I saw two problems with the previous commits:

• Focus events not requested at all
• Focus events requested too late

When testing earlier today, obviously, the first problem was averted, vim will eventually send the request.

I was however able to switch windows before the notifications got to vim, and so got into an inconsistent state because vim now thought it had the focus while it did not. This is why I wrote I'd have to remember not to switch windows immediately after starting vim.

But then, while writing this reply, I noticed that I could also avert the problem with a change of the perl code that makes urxvt send the notifications to nvim. I would therefore say that your commit fixed the second problem as well (I only noticed after I ironed out a bug in my perl code).