bug: loading issue on Neovim nightly

[Aumnescio]

kitty-scrollback started misbehaving Neovim built from source. (Tested again and it's happening on commit "76dcc7029b200e1d85024d7ba4a34c602e730dbe" as well as whatever I previously tested on.)

If the close_threshold_seconds in loading.py is lowered, kitty-scrollback starts up faster, but the content is not shown until some key is pressed.

kitty-scrollback-loading.mp4

Issue occurring on an older version of kitty-scrollback as well as on the latest release. (v6.0.0)

[mikesmithgh]

hi @Aumnescio thank you for the details and video of the issue.

I am on the latest nightly build of Neovim and do not see the issue. I am wondering if some messages may be written and waiting for user input.

1. After you open kitty-scrollback.nvim, could you perform the command :messages and let me know if you see anything?

2. What version of Kitty are you on?

3. What OS are you on?

4. Is there a specific key you have to press or is it any key to show the content?

[Aumnescio]

1. :messages is empty.
2. kitty 0.37.0
3. Pop OS 22.04
4. Seems to be absolutely any key.

I should note that it did not happen 100% of the time. Just now for testing when I swapped to nightly, the first launch did not have the delay, but after that it started happening again.

[Aumnescio]

Okay, after some further testing/realizations, the issue might not be directly with this plugin, but rather a symptom of a \ key somehow getting fed into my nvim as input on launch. (Which then causes the loading delay for kitty-scrollback) This is happening only on nightly for me so I am quite confused by this.

I enabled the showcmd option, and can see a \ character in the input queue when starting Neovim. I wonder where that is coming from..

Edit: This input is somehow coming from Kitty itself, it seems. Other terminal emulators don't show this behaviour.

[Aumnescio]

Think I have resolved the issue for now, though I do not know why, when, or how this behaviour was changed.

I had the settings:

vim.opt.timeout = false
vim.opt.timeoutlen = 420
vim.opt.ttimeout = false
vim.opt.ttimeoutlen = 5000

With these settings, I was getting the \ character in my input queue on launch, and kitty-scrollback loading was hanging.

After changing to:

vim.opt.timeout = false         -- Included for completeness.
vim.opt.timeoutlen = 420        -- Included for completeness.
vim.opt.ttimeout = true         -- This being the critical part.
vim.opt.ttimeoutlen = 9999      -- This should effectively emulate "ttimeout = false".

All problems seem to have been resolved, without any problematic side effects on my responsiveness settings.

[mikesmithgh]

@Aumnescio interesting, I was able to reproduce it by adding

      vim.g.mapleader = [[\]]
      vim.opt.timeout = false
      vim.opt.timeoutlen = 420
      vim.opt.ttimeout = false
      vim.opt.ttimeoutlen = 5000
      vim.fn.feedkeys([[\]])

to my kitty-scrollback.nvim config.

I noticed in your config that it looks like you are using / as your leader key https://github.com/Aumnescio/dotfiles/blob/585bf9f51affe62ac37c14c095ef754022f0777b/nvim/lua/keybindings/good-binds.lua#L25.

My guess at the moment is some plugin or autocmd may be sending the / key during startup. Since / is a leader key it is pausing and waiting for the next keypress.

[mikesmithgh]

reproduce-kitty-scrollback-issue.mp4