Filters/searches aren't persisted when toggling Yazi

[llakala]

Steps to reproduce:

• Open Yazi with :Yazi
• Make some kind of filter. For the purposes of this, type s and search for something (make it a search that'll give at least one result)
• Open a file
• Run :Yazi toggle
• Observe that your filter hasn't persisted

This would personally be useful for me, since I use a Yazi plugin that lets me only see git modified files (see https://github.com/yazi-rs/plugins/tree/main/vcs-files.yazi), and I'd like to be able to toggle Yazi and continue seeing only the modified files.

[mikavilpas]

Right now it's not possible, but in the future it might be.

[llakala]

Should I make an issue upstream, then?

[mikavilpas]

No, I think it should be done here instead. Yazi can't handle all possible use cases without becoming very difficult to maintain.

An idea that I have is to not force yazi to close by using snacks by folke. It could be kept open . There are many things that become possible then, but also many problems.

For example, opening a file in yazi will close it, and I think it should be changed to keep it open.

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[llakala]

Still important to me. Don't close, stalebot!

[byguid]

Would it be possible for "toggle" to hide/unhide the buffer? If that's possible, it would retain the state of Yazi, and also make it blazingly fast to open, because as of now it takes a moment to initialize every time it's shown.

[mikavilpas]

Yeah I have been thinking https://github.com/folke/snacks.nvim/blob/main/docs/terminal.md provides this out of the box, and snacks is already supported with other things out of the box.

A problem is that yazi will close by default when we press enter on a file. We would need to disable this behaviour when using yazi.nvim.

Or maybe you're talking about a use case that does not involve opening files?

[byguid]

Right, Snacks.terminal is one of the examples of this behavior. I believe neo-tree uses something similar to preserve the state and responsiveness.

Or maybe you're talking about a use case that does not involve opening files?

I meant the :Yazi toggle functionality, as OP noted, but yes, it would make sense to have the same behavior when opening files.

A problem is that yazi will close by default when we press enter on a file. We would need to disable this behaviour when using yazi.nvim.

I'm not sure I understand what do you mean that Yazi is closing when opening a file. In standalone Yazi when I open a file, the Yazi process remains alive, and as soon as I close the file, I'm back in Yazi in the same state as I left it (selection, filters etc). Or do you mean the current default behavior of the yazi.nvim plugin?

[mikavilpas]

Or do you mean the current default behavior of the yazi.nvim plugin?

Yeah, the way this plugin uses yazi right now is to pass a flag that modifies yazi's behaviour. You can try it out to see exactly with yazi --chooser-file foo.txt.

The change is that instead of keeping yazi open, it will instantly close and just write the names of the files that have been opened to that file. I'm not sure how to preserve this behaviour while also supporting a toggleable yazi. Maybe there's a way, though.

[byguid]

I see, thanks for explanation. I didn't know Yazi was running in a different mode.
There're also --local-events and --remote-events arguments. Sounds promising but I'm sure you've seen that already. I haven't figured out what they are actually for and what kinds of events they transmit. I guess they aren't useful for what we want to achieve here.

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[llakala]

Still important to me.