bug: Last search opens up with different order of results

[marcinjahn]

Did you check docs and existing issues?

• [x] I have read all the snacks.nvim docs
• [x] I have updated the plugin to the latest version before submitting this issue
• [x] I have searched the existing issues of snacks.nvim
• [x] I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)

0.10.4

Operating system/version

Fedora 41

Describe the bug

When I hit <leader>sR to see the last picker results, I'd expect the results to be ordered the say as they were the last time I saw picker. This isn't the case, my file search shows results in different order than the last time I saw it.

Steps To Reproduce

1. Look for some files with picker
2. move the cursor down to some further resutl
3. Close picker
4. Reopen the last picker search

Expected Behavior

I'd expect the ordering of results to be exactly the same as the last time I saw them.

Repro

Just the default LazyVim setup

See https://github.com/folke/snacks.nvim/issues/1521#issuecomment-2707241172

[dpetka2001]

How exactly are you triggering this? I just tested with a fresh LazyVim installation and can't seem to reproduce. Screencast following

https://github.com/user-attachments/assets/41605ae8-8eab-449a-b89f-83e9cc9d9819

[marcinjahn]

Here's what I do:

https://github.com/user-attachments/assets/ab563b96-cc4b-44b7-9194-adb2e2b74b6f

In the end of the video, I'm opening the last picker multiple times (Resume as it's called in LazyVim), and you can see that the list has slightly different ordering (e.g., sometimes format.lua is above select.lua, and in other cases it's the opposite).

In this example, I used the Files picker, but I see the same behavior with Grep picker as well, so it seems to be general issue.

The command I run in the beginning:

docker run -w /root -it --rm alpine:edge sh -uelic '
     apk add git lazygit fzf curl neovim ripgrep alpine-sdk --update
     git clone https://github.com/LazyVim/starter ~/.config/nvim
     git clone https://github.com/folke/snacks.nvim.git
     cd snacks.nvim
     nvim
   '

[dpetka2001]

I followed the exact same steps writing picker in the input field, then going with the cursor to format.lua and opening the file in a buffer and then pressing <leader>sR for resume operation (I opened and closed the picker 5-6 times with resume), but mine the cursor always stays in the format.lua file and never goes to select.lua. Wonder what the difference might be.

[dpetka2001]

Does :checkhealth snacks show any kind of error out of the ordinary?

[marcinjahn]

picker has this status in :checkhealth snacks (this is from the container setup above):

On my real neovim install (where the bug also occurs), I have:

[marcinjahn]

I followed the exact same steps writing picker in the input field, then going with the cursor to format.lua and opening the file in a buffer and then pressing <leader>sR for resume operation (I opened and closed the picker 5-6 times with resume), but mine the cursor always stays in the format.lua file and never goes to select.lua. Wonder what the difference might be.

That's odd. As my example runs the setup within a container with a clean neovim and lazyvim setup, I'd think it should be reproducible 🤔

[dpetka2001]

Unfortunately, I couldn't reproduce. Hopefully maintainer will have a better idea about what might be at fault.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[marcinjahn]

Commenting for the bot

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[marcinjahn]

Still valid

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[marcinjahn]

Bump

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[marcinjahn]

Bump

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[marcinjahn]

Bump

[jakubbortlik]

Hi @marcinjahn. This is a feature. The default sort order doesn't take filename into account - this order is determined by the underlying tool (fd or ripgrep neither of which sort their results). If you want to sort by filename also, you need to override the picker config. This should work for grep: :lua Snacks.picker.grep({args={"--sort=path"}}). For fd (for the files picker) it's not as straightforward, as it doesn't seem to have a simple flag for sorting. But you could probably use a workaround like this: :lua Snacks.picker.files({args = {"-tf", "--strip-cwd-prefix", "-X", "ls"}})

You can of course put this to your general picker config instead of a direct call.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 7 days with no activity.