3rd / image.nvim

🖼️ Bringing images to Neovim.
MIT License
1.03k stars 42 forks source link

[BUG] Error on exit from nvim #200

Closed kapral18 closed 2 months ago

kapral18 commented 2 months ago

image

nvim plugin: config https://github.com/kapral18/dotfiles/blob/1def47e06d147165040392c76c885291eb66be5a/home/dot_config/exact_nvim/exact_lua/exact_plugins/image.lua

tmux config: https://github.com/kapral18/dotfiles/blob/1def47e06d147165040392c76c885291eb66be5a/home/dot_config/tmux/tmux.conf

fish shell config: https://github.com/kapral18/dotfiles/blob/1def47e06d147165040392c76c885291eb66be5a/home/dot_config/private_fish/config.fish.tmpl

Terminal: wezterm Nvim: 0.10.1 Tmux: 3.4

3rd commented 2 months ago

Hey, do you have this issue with Kitty as well?

kapral18 commented 2 months ago

I don't use kitty. I installed it but without proper config it's unusable. Even with wezterm this doesn't happen constantly, but rather occasionally, when the tmux session hangs around on the background for long enough and then keeps happening in the row. I tried to debug and during debug session it breaks with a completely different error when evaluating the

local result = vim.fn.system("tmux display-message -p '#{" .. name .. "}'")

telling that I cannot run fn.system within loop for some reason

3rd commented 2 months ago

That should definitely not happed, I'd expect that kind of error to be thrown for everyone, maybe there was something off with the debug code, did you wrap it in vim.schedule?

kapral18 commented 2 months ago

@3rd I am using osv, I don't have custom debugging code. It fails solely within image.nvim during vimleavepre autocmd

3rd commented 2 months ago

It attempts to get the pane tty and use it for clearing, what does this output in the same pane? tmux display-message -p '#{pane_tty}' What is osv?

kapral18 commented 2 months ago

@3rd

What is osv?

osv is the popular nvim plugin debugger https://github.com/jbyuki/one-small-step-for-vimkind

tmux display-message -p '#{pane_tty}'

/dev/ttys003

3rd commented 2 months ago

It must be the debugger interaction getting weird there. Didn't encounter the original issue, wondering if it's Wezterm specific. Can you open a tmux session in Kitty and check if it happens there as well?

kapral18 commented 2 months ago

the problem is it's not happening often even in wezterm. For me to be able to track it in kitty I should configure it properly otherwise it's not workable for me as I mentioned in previous comment.

But I moved to iterm2 lately and I no longer see the issue, but also latest version of iterm2 is like 10 times faster than wezterm for me, so maybe that affects somehow

3rd commented 2 months ago

Yeah, I guess it might be Wezterm related, the graphics implementation is much much worse than in Kitty, and I'd say supporting non-Kitty terminals that implement Kitty's protocol is out of scope for the project for now. We'll add support for other backends though.

kapral18 commented 2 months ago

actually it just happened to me in iterm2 as well, I kept it hanging long enough on the background and then tried to exit the nvim.

kapral18 commented 2 months ago

oh and one more thing I disabled your plugin and all the lags I had are gone magically. Both on startup and on exit. Not hating just noticed.

3rd commented 2 months ago

added a change now to bail early in the nvim_set_decoration_provider if there were never images rendered, maybe it helps. couldn't reproduce the lag :(