Closed wookayin closed 2 years ago
Thanks, reproduced.
Thank you, the fix works for the specific scenario I reported. However, once in a while I still see a similar issue where nvim UI becomes unresponsive upon some (unknown) conditions, hitting 100% CPU. Do you have any idea if there's any good way to debug/troubleshoot so I can provide you with more debugging information?
Looking at neovim's (not lua) stacktrace, the stack is almost overflowing due to infinite recursion on redraw
:
It's weird, I can't reproduce the issue after the commit. The stack looks like caused by cmd('redraw')
. I guess some plugin change your folds. UFO_LOG=debug nvim
, the log path is ~/.cache/nvim/ufo.log
. You can also change the log level on the fly by lua require('ufo.lib.log').setLevel('debug')
Neovim version (nvim -v | head -n1)
NVIM v0.8.0-dev+1856-g58323b1fe
Operating system/version
macOS 12.x
How to reproduce the issue
nvim-ufo version: f3662fe (latest as of now). The bug was reproducible when a minimal config is used, i.e.,
require 'ufo'.setup {}
only.It's quite hard for me to specify the exact condition for this bug to happen, as I don't have a deterministic way/scenario to 100% reproduce the bug, but here's some steps:
:vsplit
to open the buffer in two different windowsExpected behavior
There should be no lag or errors and everything should work smoothly.
Actual behavior
An error message shows as a virtual text or maybe in a floating window:
decorator.lua:L203
iscmd('redraw')
. For some reason or specific to my config, some heavy routines seem to be running while redrawing the vim screen.Unfortunately, I was unable to get the stacktrace because the full error message was truncated.
Interestingly, this usually doesn't happen when a buffer is in a horizontally split. When there is no vertical split or only horizontal splits are made, the UI works fine.