search

sxyazi / yazi

💥 Blazing fast terminal file manager written in Rust, based on async I/O.
https://yazi-rs.github.io
MIT License
16.85k stars 392 forks source link

problem about previewer plugin, something about adapter. #1914

Closed ovwxxwvo closed 6 days ago

ovwxxwvo commented 1 week ago

yazi --debug output

Yazi
    Version: 0.3.3 (Arch Linux 2024-09-05)
    Debug  : false
    OS     : linux-x86_64 (unix)

Ya
    Version: 0.3.3 (Arch Linux 2024-09-05)

Emulator
    Emulator.via_env: ("tmux-256color", "tmux")
    Emulator.via_csi: Ok(Unknown([]))
    Emulator.detect : Unknown([])

Adapter
    Adapter.matches: Wayland

Desktop
    XDG_SESSION_TYPE           : Some("wayland")
    WAYLAND_DISPLAY            : Some("wayland-1")
    DISPLAY                    : None
    SWAYSOCK                   : Some("/run/user/1000/sway-ipc.1000.150012.sock")
    HYPRLAND_INSTANCE_SIGNATURE: None
    WAYFIRE_SOCKET             : None

SSH
    shared.in_ssh_connection: false

WSL
    WSL: false

Variables
    SHELL              : Some("/usr/bin/bash")
    EDITOR             : Some("nvim")
    VISUAL             : None
    YAZI_FILE_ONE      : None
    YAZI_CONFIG_HOME   : None

Text Opener
    default: Some(Opener { run: "nvim \"$@\"", block: true, orphan: false, desc: "nvim", for_: None, spread: true })
    block  : Some(Opener { run: "nvim \"$@\"", block: true, orphan: false, desc: "nvim", for_: None, spread: true })

Multiplexers
    TMUX               : true
    tmux version       : tmux 3.5a
    ZELLIJ_SESSION_NAME: None
    Zellij version     : No such file or directory (os error 2)

Dependencies
    file             : 5.45
    ueberzugpp       : No such file or directory (os error 2)
    ffmpegthumbnailer: 2.2.3
    magick           : 7.1.1-40
    fzf              : 0.55.0
    fd               : 10.2.0
    rg               : 14.1.1
    chafa            : No such file or directory (os error 2)
    zoxide           : 0.9.6
    7z               : 17.05
    7zz              : No such file or directory (os error 2)
    jq               : 1.7.1

Please describe the problem you're trying to solve

hey, mate, me again, I need help, can not move on. I have completed the preview demon & peek fn, & I found out thats no enough, what we need to do is add one Adapter, & rewrite the fn image_show & image_erase, & maybe matches fn also. Is that I can directly write a lua script to replace the fn , or I need yazi to give me an entry.

impl Adapter {
    pub async fn image_show(self, path: &Path, max: Rect) -> Result<Rect> {
    pub fn image_erase(self, area: Rect) -> Result<()> {

Would you be willing to contribute this feature?

Describe the solution you'd like

I have completed the preview demon & peek fn, & I found out thats no enough, can not contine move on.

Additional context

No response

Validations

ovwxxwvo commented 1 week ago

& I think better to have an option to let us config the adapter by ourselves,
because we know our system better. & it also make yazi faster & faster, like what you wanted.

sxyazi commented 6 days ago

I don't think this makes any sense, because Yazi already supports the Kitty graphics protocol, inline image protocols, sixel, uberzugpp, and chafa — these are currently the best and only available image backends.

I don't think there's any new tool that could do their job better. If there is, it would be better to support it directly in Yazi rather than forcing users to write highly unreliable scripts to implement it themselves since user scripts can cause conflicts with Yazi's TUI rendering when writing to stdout, which could break the entire screen during fast scrolling through the file list.

Closing as not planned

ovwxxwvo commented 6 days ago

I don't think this makes any sense, because Yazi already supports the Kitty graphics protocol, inline image protocols, sixel, uberzugpp, and chafa — these are currently the best and only available image backends.

I don't think there's any new tool that could do their job better. If there is, it would be better to support it directly in Yazi rather than forcing users to write highly unreliable scripts to implement it themselves since user scripts can cause conflicts with Yazi's TUI rendering when writing to stdout, which could break the entire screen during fast scrolling through the file list.

Closing as not planned

Just give the way to show it did not let it erase, this is a little bit funny. I already done the scripts demon & peek, & the seek will come out. But it just for sway+tmux, how can I move on.

I think the script no need to be inside yazi, I know you will not let me, but maybe a lua plugin entry with peek fn, is enough.

let it previewer inside, & can not be setup by ourselves, I told you before ueber crash my terminal down. You still think that they do their job "better", & just do nothing about it.

ovwxxwvo commented 6 days ago

I don't think this makes any sense, because Yazi already supports the Kitty graphics protocol, inline image protocols, sixel, uberzugpp, and chafa — these are currently the best and only available image backends.

I don't think there's any new tool that could do their job better. If there is, it would be better to support it directly in Yazi rather than forcing users to write highly unreliable scripts to implement it themselves since user scripts can cause conflicts with Yazi's TUI rendering when writing to stdout, which could break the entire screen during fast scrolling through the file list.

Closing as not planned

Just give the way to show it did not let it erase, this is a little bit funny. I already done the scripts demon & peek, & the seek will come out. But it just for sway+tmux, how can I move on.

I think the script no need to be inside yazi, I know you will not let me, but maybe a lua plugin entry with peek fn, is enough.

let it previewer inside, & can not be setup by ourselves, I told you before ueber crash my terminal down. You still think that they do their job "better", & just do nothing about it.

ovwxxwvo commented 6 days ago

I don't think this makes any sense, because Yazi already supports the Kitty graphics protocol, inline image protocols, sixel, uberzugpp, and chafa — these are currently the best and only available image backends.

I don't think there's any new tool that could do their job better. If there is, it would be better to support it directly in Yazi rather than forcing users to write highly unreliable scripts to implement it themselves since user scripts can cause conflicts with Yazi's TUI rendering when writing to stdout, which could break the entire screen during fast scrolling through the file list.

Closing as not planned

Just give the way to show it did not let it erase, this is a little bit funny. I already done the scripts demon & peek, & the seek will come out. But it just for sway+tmux, how can I move on.

I think the script no need to be inside yazi, I know you will not let me, but maybe a lua plugin entry with peek fn, is enough.

let it previewer inside, & can not be setup by ourselves, I told you before ueber crash my terminal down. You still think that they do their job "better", & just do nothing about it.

sxyazi commented 6 days ago

I don't have enough context to understand this feature request - if it's related to the "ueber" problem you mentioned, you should include it.

Also, stop spamming my email PLEASE, if you are unhappy with this, you are welcome to a full refund.

I'm going to lock this issue since it's no longer constructive