Wrong 'reveal' config for Linux

[majutsushi]

What system are you running Yazi on?

Linux X11

What terminal are you running Yazi in?

kitty 0.30.1

Did you try the latest code to see if this problem got fixed?

Tried, but the problem still

yazi --debug output

$ yazi --debug
Yazi
yazi 0.2.4 (VERGEN_IDEMPOTENT_OUTPUT 2024-03-10)

Environment
OS: linux-x86_64 (unix)
Debug: false

Emulator
Emulator.via_env: ("xterm-kitty", "")
Emulator.via_csi: Ok(Kitty)
Emulator.detect: Kitty

Adaptor
Adaptor.matches: Kitty

tmux
TMUX: false

Zellij
ZELLIJ_SESSION_NAME: None

Desktop
XDG_SESSION_TYPE: Some("x11")
WAYLAND_DISPLAY: None
DISPLAY: Some(":0")

Ueberzug
Version: Ok(Output { status: ExitStatus(unix_wait_status(256)), stdout: "", stderr: "Usage:\n    ueberzug layer [options]\n    ueberzug library\n    ueberzug version\n    ueberzug query_windows PIDS ...\n" })

WSL
/proc/sys/fs/binfmt_misc/WSLInterop: false


--------------------------------------------------
When reporting a bug, please also upload the `yazi.log` log file - only upload the most recent content by time.
You can find it in the "/home/jan/.local/state/yazi" directory.

Describe the bug

The last default reveal action at https://github.com/sxyazi/yazi/blob/latest/yazi-config/preset/yazi.toml#L41 seems to be incorrect, it tries to show the EXIF info instead of revealing the file in a GUI file manager. The EXIF action would probably only make sense for images.

The best "reveal" action I've found for Linux is this:

    { run = 'gtk-launch $(xdg-mime query default inode/directory) "$1"', desc = "Reveal", for = "linux" }

Unfortunately this only works if gtk-launch is installed, which probably isn't always the case. There are some alternatives listed here but it would probably require a dedicated shell script or plugin to pick the right one for the current system.

Expected Behavior

List a "Reveal" action for Linux

To Reproduce

Try to reveal a file on Linux

Configuration

No response

Anything else?

No response

[sxyazi]

Hi, I think this is expected behavior, since I didn't find a universal way to add "Reveal" for Linux, so I decided not to add it. Instead, I want to encourage users to customize it according to their needs and installed tools.

I set the description for this exiftool command as "Show EXIF" instead of "Reveal" to avoid displaying misleading text when the user presses O. However, it may not be appropriate to include it in reveal = [], perhaps it's worth a new category, but I want to keep the default configuration as simple as possible. Curious about your thoughts!

[callahad]

I also found "Show EXIF" confusing until I went source diving and read the macos and windows defaults for "Reveal"

In the absence of a script to intelligently handle various GUI file managers, I'd suggest xdg-open . or nothing would be better defaults on Linux.

[callahad]

If it's at all useful, some quick research:

• Dolphin: dolphin --select foo, or dolphin --select foo --select bar
• Nautilus: nautilus --select foo, opens multiple windows if specifying more than one path (probably not desired)
• Thunar: thunar foo, opens multiple windows if specifying more than one path (probably not desired), passing a directory opens that directory instead of selecting it

[majutsushi]

I agree with @callahad, without a better general solution just using xdg-open . would probably be good enough as the default for reveal on Linux. It would probably still make sense to move the "EXIF" action to a separate, image-specific opener though.

[sxyazi]

IIRC, xdg-open /a/b opens the directory b, i.e. CWD is /a/b, while the behavior of "reveal" should open directory a and select directory b, i.e. CWD is /a.

I think these are different, and it only works for directories. If it's a file, it won't open the GUI file manager, because the file will be opened directly in the corresponding application, such as mpv for video files.

[majutsushi]

IIRC, xdg-open /a/b opens the directory b, i.e. CWD is /a/b, while the behavior of "reveal" should open directory a and select directory b, i.e. CWD is /a.

Yes, this is correct. That's why I think it would make sense to explicitly use xdg-open . to open the current directory. This should still open the directory the currently "hovered" file is in, it just won't select it. That's what I meant with a "good enough" solution for the general case. This is only a suggestion of course, I just think it's better than not having any kind of action similar to "reveal" by default.

[sxyazi]

Ah I see, will create a PR to add it

[github-actions]

I'm going to lock this issue because it has been closed for 30 days. ⏳
This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.