Thoughts on implementing run options for custom openers, similar to ranger's launch flags?

[vide0hanz]

I would imagine that many users of yazi are likely familiar with other terminal file managers. Perhaps the most popular among these is ranger, which is very mature by comparison.

Arguably, the biggest advantage yazi has over something like ranger is asynchronous operations, which makes working with large directories over network shares a lot nicer -- ranger can get rather slow in situations like this, until all of the directory contents have been temprarily cached, especially when previews are enabled.

For those unfamiliar, ranger ships with rifle.conf as it's opener and includes helpful flags to indicate how a program should open files from it's interface, ie:

# Flags are single characters which slightly transform the command:
#   f | Fork the program, make it run in the background.
#     |   New command = setsid $command >& /dev/null &
#   r | Execute the command with root permissions
#     |   New command = sudo $command
#   t | Run the program in a new terminal.  If $TERMCMD is not defined,
#     | rifle will attempt to extract it from $TERM.
#     |   New command = $TERMCMD -e $command

For example -- focusing on the f flag -- let's say you wanted to play a video file from within ranger with mpv, you would have a line in ranger's rifle.conf like this:

#--------------------------------------------
# Video/Audio with a GUI
#-------------------------------------------

mime ^video,       has mpv,      X, flag f = mpv -- "$@"

This translates to: "If the selected file is a video mimetype, play it in mpv and fork the process with setsid"; This lets the user continue to use the file manager while the video appears in a new window, and will remain running after the parent process has exited.

To do the same on yazi would probably look like this (not tested):

[opener]
play = [
    { run = 'setsid mpv "$@"', desc = "Play video in a new window", for = "unix" },
[

*NOTE: for = "unix" is specified here because I do not know of an equivalent to setsid for Windows, but I'm sure one exists.

Yazi already has orphan which effectively already does what I'm referring to in the example provided, but the key difference here with using setsid to fork the process allows for more user control over the process tree in their preferred environment.

Example use case: window swallowing

Window "swallowing" is a concept familair to many users of tiling window mangers on X11. When available, this allows GUI applications invoked from a command line to take the place of the terminal window it was called with. Otherwise, starting a GUI application from a terminal emulator will open the GUI application in a separate window and leave the terminal in a "useless" state until the child process exits.

Of course, it is trivial to prepend setsid to commands in the [opener] should the user want it, and those who do are very likely to already know how to do this. Purely from a convenience/familiarity standpoint though, I was thinking an additional option in the Opener struct could make for a cleaner and more uniform syntax for yazi.toml.

Thoughts?

[sxyazi]

If I got you right, you're saying to introduce a new setsid option for each opener rule:

[opener]
play = [
-    { run = 'setsid mpv "$@"', desc = "Play video in a new window", for = "unix" },
+    { run = 'mpv "$@"', desc = "Play video in a new window", for = "unix", setsid = true },
[

But it seems there's not much advantage over adding it directly to run, because you'd still need to set it for each opener rule, and we'd also need to consider cross-platform issues.

Apart from Linux (like macOS, Windows, and Android), is setsid even available on those systems? And does it make sense to set it there, since those systems usually don't use window managers? Are there any other real-world use cases where this would be effective?

[vide0hanz]

Yeah, pretty much. Something that exists alongside orphan and block as another option that can safely be omitted entirely. I was thinking something like fork=true.

I am not aware of a setsid equivalent for windows, and digging a little bit, it seems that orphan=true may already be the closest thing to it in this context.

It's certainly no big deal prepending setsid to the command in the example I provided earlier, but it just got me wondering if there was any interest in exposing it as an option in a similar way to orphan and block are.

That said, I did some digging into the source yesterday while looking for solutions to a different problem I had, and now I'm not sure if I understand entirely how orphan and block are implemented; are these simply just the same subshell arguments that can be added to commands defined in the key map?