mini.files: Preview buffer sometimes doesn't update until the directory is left and reopened

[cloone8]

Contributing guidelines

• [X] I have read CONTRIBUTING.md
• [X] I have read CODE_OF_CONDUCT.md
• [X] I have updated 'mini.nvim' to latest version

Module(s)

mini.files

Description

Intermittently, the preview buffer of mini.files doesn't seem to want to update. It seems to happen at random (at least, I've been unable to find a pattern thusfar), and also stops at random. Thus, I've been unable to find a series of actions that reproduce the problem consistently. I've noticed it happens more often when I'm scrolling through files quickly, but even this is not a 100% guarantee.

I've attached a short clip of one instance where I've been able to catch it happening:

https://github.com/echasnovski/mini.nvim/assets/11874555/ced391cf-7bd7-4d1c-8c9b-3dc9b4da51b2

I can imagine this is a pretty weird one to debug, so let me know if any more information is needed or if I can do anything to help.

Neovim version

0.9.5

Steps to reproduce

I've been unable to find a 100% reproducable example. I'm trying to find one, and will update this if I manage to.

Expected behavior

Mini.files preview buffer updates in sync with the cursor

Actual behavior

https://github.com/echasnovski/mini.nvim/assets/11874555/ced391cf-7bd7-4d1c-8c9b-3dc9b4da51b2

[echasnovski]

Thanks for the issue!

Unfortunately, I can not reproduce.

I can imagine this is a pretty weird one to debug, so let me know if any more information is needed or if I can do anything to help.

The best start would be to create a separate clean config which contains only 'mini.files' and try to reproduce there. You can use 'init-deps-example.lua' as a template and NVIM_APPNAME environment variable to run a separate config (see :h NVIM_APPNAME, but basically create a '~/.config/nvim-minifiles' directory with a file 'init.lua' in it; then execute NVIM_APPNAME=nvim-minifiles nvim to run that as a separate config).

If can not reproduce there, then it doesn't look like a 'mini.files' issue. The next step would be to bisect config to see the culprit.

[cloone8]

Thanks for the issue!

Unfortunately, I can not reproduce.

I can imagine this is a pretty weird one to debug, so let me know if any more information is needed or if I can do anything to help.

The best start would be to create a separate clean config which contains only 'mini.files' and try to reproduce there. You can use 'init-deps-example.lua' as a template and NVIM_APPNAME environment variable to run a separate config (see :h NVIM_APPNAME, but basically create a '~/.config/nvim-minifiles' directory with a file 'init.lua' in it; then execute NVIM_APPNAME=nvim-minifiles nvim to run that as a separate config).

If can not reproduce there, then it doesn't look like a 'mini.files' issue. The next step would be to bisect config to see the culprit.

Yeah, that makes sense. I don't expect anyone to be able to reasonably debug this without more information. I'll try to create a minimal config and maybe find a repo that has this problem more frequently than others.

[echasnovski]

@cloone8, I am going to close this as there is no robust reproduction steps. If you happen to find them, please add a comment here.

[echasnovski]

@cloone8, in #948 this seems to have been narrowed down to depend on the exact width of the total window. For example, if it is wide enough to contain "focus + non-focus + non-focus" but not wide enough to contain "focus + preview + non-focus", there was a flicker with some unwanted bookkeeping consequences.

I think this should be resolved on latest main. Please feel free to re-report if you still encounter this issue after updating the plugin (even without reproducible example).

[cloone8]

@cloone8, in #948 this seems to have been narrowed down to depend on the exact width of the total window. For example, if it is wide enough to contain "focus + non-focus + non-focus" but not wide enough to contain "focus + preview + non-focus", there was a flicker with some unwanted bookkeeping consequences.

I think this should be resolved on latest main. Please feel free to re-report if you still encounter this issue after updating the plugin (even without reproducible example).

Wonderful! I had honestly given up trying to find a reproducible example. I'll update and will re-open if I encounter the same problem. Thanks a lot!