Neovim version: NVIM v0.4.3 installed via brew
OS: osx
Minimal vimrc:
set lazyredraw
Repro steps:
/ and type some characters until the cursor goes invisibleWoah I've never heard of this option. I will look into it.
I cannot reproduce this issue. I am running neovim 4.2 and do not see the problem
I just updated to nightly and don't see the issue their either.
He just found the setting I lost, lazyredraw is causing ~#53~ #58 for me.
I remember reading about lazyredraw here and adding it to this machines init.vim, but I never put that into my backup init.vim.
That's why the problem disappeared when I restored my usual rc files.
Until the cause is found using set nolazyredraw instead of set lazyredraw will fix it.
Wait what. Lazyredraw is causing a font load error for you?
I meant #58 sorry for the confusion. 馃槃
Ah that makes much more sense. And now that you mention it, I've noticed this happening on my machine now as well. I'm considering making an upstream neovim issue as I don't think it makes sense for the cursor to ever move to the powerline. Thoughts?
Oh also I can now repro the above steps. Thats a very weird bug
I need better logging to track this down
Yes reading the issue on the vim-sensible project makes it pretty clear that lazyredraw not only causing issues with some terminals but there are also reports of nvim completely breaking because of it. Maybe you can ignore this setting somehow?
Weirdly I'm not using the setting at all its all internal stuff. I could track the option and disable it with a message, but that feels like a hack since it definitely improves macro performance...
Does it though in neovide? As I understand it lazyredraw should only make sense in a terminal context because the way you draw things is different than a terminal would do it. Also your drawing loop isn't tied to the neovim update loop isn't it?
Oh very interesting. The bug happens even without lazyredraw. Searching, typing random characters, and then pressing escape causes the cursor to stay missing.
I have no idea what lazyredraw does.
Neovide's render loop is not tied to the neovim update loop so youre probably right. That said, the jumping the cursor to the command line is clearly an internal effect of lazyredraw so I'm not sure whats happening.
I guess it does what it says in the name.
NOTE: The next few lines are just based on reading on neovim and speculation on how it works. I have never implemented a neovim client nor worked on neovim.
Even tough neovide is drawing everything, lazyredraw probably activates something in vim that reduces the amount of drawing that is happening in the context of a terminal. My understanding is that building your own neovim client is all about IPC and if neovim does less it will generate less events or not all.
In the terminal that is okay because there usually some default behaviour that makes the cursor go back but external applications have to either also implement that behaviour or just ignore it.
EDIT: Also as long there is evidence that even neovim get it wrong at the moment I would just make it so that lazydraw get's ignored. You are not lazy drawing as far as I can tell.
This seems reasonable to me. Disabling lazyredraw is a good plan
Done. Disabling on startup. If this causes problems, either open an issue or comment here and I will figure something more out.
fwiw this is probably something that should be resolved in Nvim core, since it is intended that multiple UIs (including TUI) may be attached to one Nvim server. No editor option should break the UI protocol...
Interesting. Would you like me to make an issue in nvim? I can give some details and link back to this issue.
I can give some details and link back to this issue.
would be great!
Swapping this issue over to the original issue
The original issue is an upstream problem which I believe will be fixed by https://github.com/KillTheMule/nvim-rs/pull/13 or something similar.
This should be fixed.
So be clear, is lazyredraw supported in neovide? I actually find this setting to be really helpful performance wise in both terminal vim and nvim-qt
There is an upstream issue here: https://github.com/neovim/neovim/issues/11806 Until the core issue is fixed, it is not supported.