Awesome! I'll review it ASAP.

It seems meaningless to write the file list to stdout. Currently, Yazi writes the TUI to stdout, so using yazi --chooser-stdout > path.txt will prevent the TUI from displaying.

AFAIK, fzf writes the TUI to stderr and outputs the selected file path to stdout.

it enables using stdout after the tui closes to enable further editor support without using temp files e.g.

AFAIK, fzf writes the TUI to stderr and outputs the selected file path to stdout.

How big of a change would this be in yazi? Seems overall like a good idea. This would enable pipes and a more linux like behavior.

it enables using stdout after the tui closes to enable further editor support without using temp files e.g.

Sorry I didn't understand this, how should I use --chooser-stdout for now?

In nvim i am using the following function to read directly from buffer without a tmpfile to open a selected file:

function M.close()
    local lines = vim.api.nvim_buf_get_lines(0, 0, -1, false)

    if #lines == 0 then
        return 1
    end

    local path = lines[1]
    if not file_exists(path) then
        return 1
    end

    vim.cmd("e " .. path)
    vim.cmd("bd#")
    vim.cmd("filetype detect")

    return 0
end

Like i wrote initially, the change enables my current workflows. This is one example.

AFAIK, fzf writes the TUI to stderr and outputs the selected file path to stdout.

How big of a change would this be in yazi? Seems overall like a good idea. This would enable pipes and a more linux like behavior.

I quickly checked the ratatui and crossterm libraries used by Yazi, but couldn't find any relevant information. I'm not sure how to change it and how much effort it would involve.

Also I don't think writing TUI to stderr is appropriate for TUI apps because it's not like fzf, which purely outputs the user-selected path to stdout, and the UI is just its accessory.

In nvim i am using the following function to read directly from buffer without a tmpfile to open a selected file:

function M.close()
    local lines = vim.api.nvim_buf_get_lines(0, 0, -1, false)

    if #lines == 0 then
        return 1
    end

    local path = lines[1]
    if not file_exists(path) then
        return 1
    end

    vim.cmd("e " .. path)
    vim.cmd("bd#")
    vim.cmd("filetype detect")

    return 0
end

Like i wrote initially, the change enables my current workflows. This is one example.

How do you select files in Yazi without the UI? Does nvim separate escape sequences from the selected file list in stdout?

FYI: https://ratatui.rs/faq/#should-i-use-stdout-or-stderr

Seems like a one place edit.

How do you select files in Yazi without the UI? Does nvim separate escape sequences from the selected file list in stdout?

Seems like it. Here the current output when im leaving the term open:

I found this ratatui/ratatui-website#274; it seems that stderr might be slower than stdout. Yazi needs to transcode a large number of images to the terminal, and this could become quite noticeable.

Ok, how should we proceed? Adding niche functionallity, and a refactoring to handle all quit actions at the same stage?

Due to the performance issues mentioned above, I've decided not to switch Yazi from stdout to stderr.

This would require more efforts in terms of performance optimization, and I still question whether it's suitable for a TUI application - afaik, it's an unconventional approach, a bit tricky, and I've only seen it in fzf.

Therefore, I would like to remove chooser_stdout and only keep the refactored results.

feel free. Thus, no switch for me from lf sadly.

Btw. i meant to add the flag without switching to stderr.

I'm sorry that Yazi couldn't match your workflow.

In fact, I never really understood what your X issue was, why only stdout would fit into your workflow, and why files wouldn't work, or what your workflow even looked like, and whether there's a workaround here, like #112 (comment).

Anyway, feel free to close this PR if it's no longer valuable to you. Sorry again for any inconvenience it may have caused you.

Everything is cool! Please take the refactoring. I hope it helps! Was a cool finger practice :D

The link is interesting, maybe i can switch regardless (didnt even knew this is an option)

edit: i removed the flag and left the refactoring intact

For what it's worth, you might want to take a look at orhun/personal-blog#24 to know more about stdout/stderr performance.

You can make stderr as fast as stdout by buffering it (code in the article) by wrapping stderr in a BufWriter.

For what it's worth, you might want to take a look at orhun/personal-blog#24 to know more about stdout/stderr performance.

You can make stderr as fast as stdout by buffering it (code in the article) by wrapping stderr in a BufWriter.

Funny. Thus, a buffered stderr should lead to better perf than the normal stdout in crossterm :D Something like this (untested!) would do the trick?

Terminal::new(CrosstermBackend::new(BufWriter::new(stderr())))?;

Funny. Thus, a buffered stderr should lead to better perf than the normal stdout in crossterm :D Something like this (untested!) would do the trick?

In theory yes, I won't explain what the article did better than me but the tldr is stdout is line buffered while stderr in unbuffered by default.

LineWriter::new(stderr()) is the exact same as stdout(), BufWriter should in theory be a little bit faster for a TUI.

The article is cool! I think it will clear up all my doubts about stderr. I'll read it and reconsider supporting stderr.

let me know if i should convert the removal of the flag commit. Otherwise the pr should only contain the refactoring.

Let me make some changes and merge it first.

I'll try to add stderr support in the subsequent PR, which will happen in the next target v0.2.1, not this target (v0.2.0).

Thank you for the PR, let me merge it now.

I'll try to add stderr support in the subsequent PR, which will happen in the next target v0.2.1, not this target (v0.2.0).

Hi, long time no see!

Yazi switched to stderr yesterday, so stdout can now be used for outputting the CWD. With the latest main branch, you can use

yazi --cwd-file /dev/stdout | cat

to get the CWD when exiting.