feature: [explorer]Improve the performance of cursor jump

[xian-wen]

Did you check the docs?

• I have read all the snacks.nvim docs

Is your feature request related to a problem? Please describe.

Hi, is it possible to improve the performance of the cursor jump in Snacks.explorer? Currently, it is a little bit sluggish, as you can see in the recording of the comparison between neo-tree and Snacks.explorer.
neo-tree:

Snacks.explorer:

Describe the solution you'd like

Just make the cursor jump a little bit more smoother.

Describe alternatives you've considered

Borrow the solution from neo-tree?

Additional context

No response

[folke]

That's not normal. It seems to be the git status command that is slow on your machine for some reason. Any ideas?

[folke]

Disable git status to test

[xian-wen]

Below is the time of git status, a little bit too long:

[xian-wen]

So is it possible to not always run the git status command every time the keymap is triggered?

[xian-wen]

I will make a recording after disabling the git_status, which improves a lot, but still feels jumpy.

[folke]

That is extremely slow.
The same command for me runs in 5ms so 1000x faster than in your case.

What about the fd command?

There really must be something wrongly configured somewhere on your system.

I will however change it so that slow git commands don't prevent navigating the list.

[xian-wen]

Hi, below is the recording with git_status = false:

[xian-wen]

It is not slow, but a little bit jumpy?

[xian-wen]

That is extremely slow.
The same command for me runs in 5ms so 1000x faster than in your case.

This is just an academic docker environment, Ubuntu 22.04. I think there is no problem for fd since Snacks.picker runs fast.

[xian-wen]

Below is the recording of Snacks.picker, at least it is better than telescope and not slower than fzf-lua:

[folke]

I just changed it so that git status no longer blocks anything.
But that of course won't fix your 5s execution time. It will just make sure you will be able to use the explorer
without waiting till it finished.

Closing.

[xian-wen]

I find that neo-tree also displays the icons asynchronously when opening the first time, but when running the second, third, and so forth, time, the icons are displayed instantly. Maybe it uses some cache trick.

[folke]

you mean the git icons? So does the snacks picker. Did you update?

[xian-wen]

Yes, I have updated to the latest version of Snacks. I mean the git icons displayed in Snacks.explorer each time just like they displayed in neo-tree the first time. When they displayed the following times in neo-tree, I cannot see any delays.

[folke]

ok, you probably mean the directory status symbols.

[folke]

Just changed that as well. You should no longer see the delays for git status.

[xian-wen]

Below is the recording of the comparison between neo-tree and Snacks.explorer, pay attention to the icons:
neo-tree:

Snacks.explorer:

As we can see, neo-tree also takes some time to display the icons the first time, but later, it displays extremely fast. It must use some cache tricks I think.

[folke]

ok, now I understand what you mean.
I don't keep the git status cache in betwen opening the explorer. Will chaneg

[folke]

And I also had pushed a 1 second sleep for testing, which didn't help :)

[folke]

try again

[xian-wen]

Awesome! Thank you so much.

[xian-wen]

Hi, folke, sorry to bother you once again. I just want Snacks.explorer to be better. Is it possible to improve the user experience when closing and opening a node? Currently, I could clearly see something like a refresh when closing and opening, which does not exist in neo-tree, as you can see in the recordings shown below:
neo-tree:

Snacks.explorer:

[folke]

This is getting a bit annoying tbh. On my laptop there's literally no visible delay. Never has been before I started all these changes.

I can indeed change it, but seriously, just fix your computer...

[xian-wen]

Yeah, this is indeed annoying, sorry once again. This problem does not exist on my WSL. On WSL, everything feels smooth and fast. And I also cannot see any visible delay. It just happens on a docker environment, which might also be used by other people.
Snacks.explorer on WSL:

[folke]

Is there a hidden or ignored file in there?

[xian-wen]

Just one code directory, all others are dotfiles, which is shown when h is toggled on.

[folke]

fixed

[xian-wen]

Looks pretty beautiful. Thank you so much. I think my dream file explorer has been born. I have been sitting in front of my computer and refreshing the Snacks repo every few minutes. I am so excited and appreciated for what you have done. Have a good night. On my timezone, it is 4:15 AM now.🤣

[folke]

Thank you and get some sleep! :)

[xian-wen]

Hi, when watch is disabled, does this mean we can no longer track the file status? Since there is no git status icon when a file has been changed.

[xian-wen]

Also, when explorer is opened, the content in the window has been changed to the top view of the buffer. After closing, the content is back. As you can see in the above recording.

[folke]

When the file watcher is disabled, only buffer writes and lazygit terminal closes will result in a git refresh.
On linux, you can install inotify-tools. That will be used when available and doesn't have the associated issues like you experienced before.

I can't reproduce that issues when the explorer opened. But I'm also not sure I fully understand what you mean.

[xian-wen]

I mean before <Leader>e is pressed, the cursor is on Line 86, i.e., the visible range is [66, 96], while after the explorer is opened, the visible range in the right window is [1, 31], i.e., the first 31 lines are shown.

[folke]

Did you enable the main preview for explorer?

[folke]

Just tried with the minimal repro and also can't reproduce this there

[xian-wen]

I think the problem comes from the preview, when I have

layout = { enabled = false, preview = "main" }

removed,
there is no such issue.

[xian-wen]

Sorry, my bad. The config should be:

            layout = {
              preview = {
                enabled = false,
                main = true,
              },
            },

[xian-wen]

I just tested LazyVim in both WSL and docker, the problem still exists when toggle in "main" is set, and disappears when this is unset.

[xian-wen]

I find the problem, enabled = false seems does not work. When the explorer is opened, with the above config, preview is toggled on by default, so all files are in preview state, thus only the top view is shown. When I press P, the preview is toggled off, and the cursor line is back.

[folke]

fixed

[xian-wen]

Awesome! Thank you so much.

[xian-wen]

On linux, you can install inotify-tools. That will be used when available and doesn't have the associated issues like you experienced before.

I have inotify-tools installed, and inotifywait is executable, however, git signs are still not shown no matter how long I wait. I need to reopen neovim to see the git icons, :e! also does not work.

[folke]

You no longer need inotity-tools.

I've changed the implementation since to no longer use NEovim's file watcher implementation,
since it's terrible for performance.

My new implementation works on all platforms, without any additional files needed.

[xian-wen]

I have uninstalled inotify-tools. There are still no git signs displayed when a file has changed.

[folke]

Can you check again?

[xian-wen]

I just updated and tested with LazyVim, nothing has changed, on both WSL and docker.

[folke]

This is really annoying since I can't reproduce it.
IS there anything special about the directory or files you're doing this with?

Start with opening neovim from an actual project diretcory.
open a file from that project
see if it then works.

There's nothing for me to fix if I can't reproduce it.

[xian-wen]

I just run lazyvim in .dofiles on WSL, then press f to find the file ./.config/lazyvim/config/options.lua, then add an option, no matter I updated the file or not, git status icons are not updated in explorer.

[folke]

ok, I can reproduce it in the exact same way indeed.

[folke]

If you'd keep the explorer open it would update properly.

[xian-wen]

Yeah. Indeed. 🤣 But usually, we would like to code in the full-screen, as it is relatively small on a laptop.

[folke]

ok, check again.

[xian-wen]

Tested, OK! Thank you so much.