dont render if the user is in command-line-window

[jonboh]

This prevents spamming the user with errors due to actions not allowed in command-line-window. It closes #128.

Now when the user opens the command-line-window image.nvim will stop rendering until the user closes the window which should not be a problem for usability.

[3rd]

Thanks for the PR! I think we need a more general way to prevent this, not just for window-attached images, but what is weird is that I can't reproduce it. How do you trigger it? Maybe we find a replacement for the nvim_get_current_win weirdness, will investigate.

[jonboh]

That's strange, are you able to open the command-line-window while an image is rendered and you don't get the error? I've tried disabling noice.nvim just in case and I still reproduce it. I'm going to try to reproduce it with a lighter weight configuration.

To trigger it, I just open a file that renders an image (either a .png a .norg or a .md), and then press q:, which will open the command-line-window and immediately start throwing errors.

[jonboh]

I've reproduce it with a very minimal configuration (just image.nvim). The terminal emulator is kitty (in wezterm I also reproduce it (same kitty backend)). https://github.com/3rd/image.nvim/assets/31407988/61aa77d3-e623-45f2-9d66-0b3cdcc446b4

This is the full init.lua loaded in the video (generated with nixvim)

vim.cmd([[

]])

vim.loader.disable()
-- Ignore the user lua configuration
vim.opt.runtimepath:remove(vim.fn.stdpath('config'))              -- ~/.config/nvim
vim.opt.runtimepath:remove(vim.fn.stdpath('config') .. "/after")  -- ~/.config/nvim/after
vim.opt.runtimepath:remove(vim.fn.stdpath('data') .. "/site")     -- ~/.local/share/nvim/site

vim.cmd([[

]])
require('image').setup({})

[3rd]

Very weird... I'm on Nix as well, but not using nixvim, my version is NVIM v0.10.0-dev-1813661

https://github.com/3rd/image.nvim/assets/59587503/4c38196a-6a92-4f34-a819-8ae4d8c1f481

[3rd]

Aaa, I see now, the command-line window it's something else. You live you learn :joy: The place you've picked for the change is good, but is there any way we could check if the window with the image.window id is a cmdline window instead of the current one?

[jonboh]

hehe no problem, I find it to be a very useful feature :)

I'm not sure that there's going to be a good way to check apart from using getcmdwintype(). In the help page it is said that it is a special kind of window, and the buffer properties that we could check are not very specific (I imagine one could generate a window that is not a command-line-window that would have these properties):

Some options are set when the command-line window is opened:
'filetype'  "vim", when editing an Ex command-line; this starts Vim syntax
        highlighting if it was enabled
'rightleft' off
'modifiable'    on
'buftype'   "nofile"
'swapfile'  off

From the help page we can assume that there is no way to leave command-line-window without closing it, so any case in which getcmdwintype() returns '' can be assumed to be safe (the command-line-window will not be open), and in the case it returns something, it means that the cursor is on it and the operation should not be attempted because it will fail.

[jonboh]

I've moved the place in which the check is done to image.lua instead of renderer.lua. I noticed that the images were cleared when the command-line-window was open, with this last commit they should stay in place (but not updated until the command-line-window is closed):