[Feature Request] only open files with certain yazi opener in nvim, so only files that are meant to be opened in editor

[aMOPel]

It often happens to me that I want to open a pdf, picture or video with yazi. sometimes even while in nvim.
Because the plugin intercepts the open mappings in yazi it sends the files to nvim, which just results in binary soup.

Currently I circumvent this by having an interactive open mapping, which is not intercepted. But I still sometimes forget to use it.

Is there some way to make yazi.nvim stop opening media files? After all I already define how to open files in yazi.toml in open.rules.
Basically I want yazi.nvim to only open files in nvim, if they are using the "edit" opener and otherwise just defer to yazi.

I didn't see an obvious solution in the docs.

y --version
Yazi 0.4.2 (Nixpkgs 2024-12-20)

yazi.nvim version 2025-01-18

Thanks for your work on the plugin. It's amazing. I especially appreciate the lsp integration 🙏

[mikavilpas]

Hi, can you show what your config looks like (yazi.toml)? I'd like to see what kinds of rules you want to achieve.

I'm thinking maybe you can check if this yazi.nvim environment variable is present in the yazi session and just run nothing if it is

yazi.nvim/lua/yazi/process/yazi_process.lua

Lines 46 to 50 in 69c6406

	env = {
	-- expose NVIM_CWD so that yazi keybindings can use it to offer basic
	-- neovim specific functionality
	NVIM_CWD = vim.uv.cwd(),
	},

[aMOPel]

I think my config is pretty close to the default:

[opener]
edit = [
	{ run = '${EDITOR:-vi} "$@"', desc = "$EDITOR", block = true, for = "unix" },
]
open = [
	{ run = 'xdg-open "$1"',                desc = "Open", for = "linux", orphan=true },
]
reveal = [
	{ run = 'xdg-open "$(dirname "$1")"',           desc = "Reveal", for = "linux" },
	{ run = '''exiftool "$1"; echo "Press enter to exit"; read _''', block = true, desc = "Show EXIF", for = "unix" },
]
extract = [
	{ run = 'ya pub extract --list "$@"', desc = "Extract here", for = "unix" },
]

[open]
rules = [
	# Folder
	{ name = "*/", use = [ "edit", "open", "reveal" ] },
	# Text
	{ mime = "text/*", use = [ "edit", "reveal", "open" ] },
	# Image
	{ mime = "image/*", use = [ "open", "reveal" ] },
	# Media
	{ mime = "{audio,video}/*", use = [ "open", "reveal" ] },
	# Archive
	{ mime = "application/{zip,rar,7z*,tar,gzip,xz,zstd,bzip*,lzma,compress,archive,cpio,arj,xar,ms-cab*}", use = [ "extract", "reveal" ] },
	# JSON
	{ mime = "application/{json,ndjson}", use = [ "edit", "reveal" ] },
	{ mime = "*/javascript", use = [ "edit", "reveal" ] },
  # pdf
	{ mime = "application/pdf", use = ["open", "edit", "reveal"] },
	# Empty file
	{ mime = "inode/empty", use = [ "edit", "reveal" ] },
	# Fallback
	{ name = "*", use = [ "open", "reveal" ] },
]

the way you answer makes it seem like you don't have that problem. how do you open a pdf or whatever with yazi while in nvim?

[mikavilpas]

I very rarely need to do that, so I just never thought this could be a use case. I mostly work with text files.

@sxyazi would you have an idea if a case like this could be/already is supported? Right now yazi.nvim just opens whatever yazi writes in its --chooser-file.

Maybe there's a way to prevent opening unwanted files when yazi.nvim is open, but to allow opening them outside of yazi.nvim. I tried to do this with mikavilpas/dotfiles@cd6977d but it still seems to open the file for me. 🤔

[sxyazi]

If the user selects multiple files to open, some of which are text files while others are non-text files, what is its behavior?

[mikavilpas]

Right now everything is opened. Maybe the non text files should be skipped, what would you say
@aMOPel

[aMOPel]

I tried to do this with mikavilpas/dotfiles@cd6977d but it still seems to open the file for me.

The way I understand it, your opener just does nothing if opened inside nvim. Just doing nothing if it's in nvim is not what I'm aiming to do, though.

I want yazi.nvim to open files inside nvim when they use the edit opener, i.e. files that are meant for the editor.

And otherwise it should behave normally as if it were outside of nvim. So it should open other files with xdg-open in my case and then a new window pops up or whatever.

To phrase it another way, yazi.nvim should only intercept "open events" if a certain opener (in my case "edit") is used, ideally that is configurable.

Apparently that isn't easy with the current yazi API/yazi.nvim implementation, though.

I'm just stating what I think would be ideal.

[sxyazi]

OK, I can add a new --no-chooser option to the open command that always runs Yazi's opener rules and ignores yazi.nvim's --chooser-file.

Then, you set up an opener for the mimetype you want to open in yazi.nvim like this:

# Publish event to yazi.nvim if we're already in Neovim, otherwise open Neovim for text files as normal
{ mime = "text/*", run = '[ -n "$NVIM" ] && ya pub-to 0 my-event --str "$1" || nvim "$1"' }

yazi.nvim subscribes to my-event and, when it receives it, opens the file in Neovim.

See https://yazi-rs.github.io/docs/dds for details.

[aMOPel]

does this then not break functionality in yazi.nvim? what is yazi.nvim using the chooser-file for?

I don't know enough implementation details here to know if it's feasible, but I think the cleanest solution from a user perspective would be if yazi.nvim did some filtering for the opener by exploiting some yazi api. And then yazi.nvim just exposes an option that let's the user say for what openers to open with yazi.nvim and for what openers to defer that decision to yazi itself. After all the user already specified in the settings which files they want to open with an editor and which not.

But I understand, if that's infeasible.

[mikavilpas]

The integration is quite simplistic right now - basically yazi writes the files it has opened to a file, and yazi.nvim reads that file. This is how opening file(s) works

sequenceDiagram

participant neovim
participant yazi.nvim
participant yazi

neovim->>yazi.nvim: open yazi.nvim
yazi.nvim->>yazi: open and display yazi
yazi->>yazi: user selects a file and opens it with <Enter>
yazi->>yazi: write opened file path(s) to --chooser-file
yazi->>yazi.nvim: yazi is closed
yazi.nvim->>yazi.nvim: read --chooser-file
yazi.nvim->>neovim: open and display the file(s)

Loading

I think what @sxyazi proposed would look like this

sequenceDiagram

participant neovim
participant yazi.nvim
participant yazi

neovim->>yazi.nvim: open yazi.nvim
yazi.nvim->>yazi: open and display yazi
yazi->>yazi: user selects a file and opens it with <Enter>
note over yazi: the user can ignore the event in their opener config
yazi->>yazi.nvim: send event about opening the file
yazi.nvim->>neovim: open and display the file(s)

Loading

I think this is a good idea. It looks like yazi stays open with this design, but for now I can make it close in yazi.nvim when a file has been opened this way.

In the future I want to enable an option for having yazi open for a long time instead of constantly closing it. Maybe at that stage it can be some kind of configurable option.

[aMOPel]

I see. I somehow assumed that yazi.nvim would communicate to yazi about open files using yazi's dds feature, but I also just saw that yazi does not have event kinds for opening files. also the dds event kinds seem to be emitted after something happend, so they don't seem to be made for intercepting any actions, i.e. preventing the default behaviour and replacing it with something else. That's basically what my suggestion above would require, so I was thinking about this all backwards.

I also thought about the possibility of yazi.nvim, being a plugin in nvim, having a companion plugin in yazi and those two work together to achieve better integration. but also in yazi's plugin api I didn't see anything about intercepting and preventing events, or hooking into the openers or similar. so nevermind.

@sxyazi 's solution above seems great 👍

[mikavilpas]

I also thought about the possibility of yazi.nvim, being a plugin in nvim, having a companion plugin in yazi and those two work together to achieve better integration

This is something I'd like yazi.nvim to eventually be like, actually. It would be great to have much more control over how yazi behaves in yazi.nvim. A companion plugin would solve it since it would have access to yazi's internal lua apis which are quite powerful.

However, a problem at this stage is configuring yazi to use this kind of plugin. I haven't been able to figure out how to do that in a user-friendly manner yet, as yazi is designed to be configured via a static file (actually 3 files, see the docs).

I'm still hopeful that a good solution will be found for this in the future, but that means that right now there still is, should I say, "some assembly required" to make things work 🙂

[aMOPel]

sounds amazing! looking forward to a tighter integration

as yazi is designed to be configured via a static file

you mean you would like to dynamically change yazi's configuration, like keymaps, when yazi is started inside neovim?

I mean there is this empty section in the docs about a config api for plugins.

https://yazi-rs.github.io/docs/plugins/config

talking about "boot", which could refer to some access to the static config.

In the code https://github.com/sxyazi/yazi/tree/main/yazi-plugin/src/config

I didn't see anything about access to the config from lua though.

so far there is just some code about fetchers, spotters, preloaders and previewers from the config

			match key {
				b"fetchers" => Plugin::fetchers(lua)?,
				b"spotter" => Plugin::spotter(lua)?,
				b"preloaders" => Plugin::preloaders(lua)?,
				b"previewer" => Plugin::previewer(lua)?,
				_ => return Ok(Value::Nil),
			}

and about runtime information

			match key {
				b"args" => Self::args(lua)?,
				b"term" => Self::term(lua)?,
				b"mgr" => Self::mgr(lua)?,
				b"plugin" => super::Plugin::compose(lua)?,
				b"preview" => Self::preview(lua)?,
				b"tasks" => Self::tasks(lua)?,
				_ => return Ok(Value::Nil),
			}

[github-actions]

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