thanks for creating this ! I used to use ranger but was tempted by joshuto for the rust bonus but either choice had issues and I feel yazi has strong foundamentals and can become the best choice for me:

• (image & text) preview by default !
• it was the fastest when opening my 200GB /nix/store that joshuto and ranger have difficulty with. I believe it could be even better and refresh the listing dynamically (I still had to wait ~8 sec) but it's much better than the other two.

The feature I miss the most currently is "search" or "filter". In ranger/joshuto, I could type / to start typing a folder name and go to it. Maybe it's possible in yazi but I couldn't find how ?

NB: nitpicks: PageUp and PageDown are not bound byu default and when the prompt to quit appears asking for "yes or no", I think it should quit on "y" press while right now I had to press "Enter" too.

When I try to Enter on the folder, which is using exec = "open" (I know it is saying Enter is to open a file instead of a folder), it will make the open task into a background process, which is in error status, and when you try to investigate the task, it will say

: line 1: open: command not found
Exited with status code: 127

yazi 0.1.4-1
Arch Linux

Actually, what ranger does this: if it is a folder, open will cd into the folder, if it is a file, open the file, which a new command like open_or_enter to combine open and enter of yazi into one can be provided so we don't have to care about whether the item is a folder or file anymore.

Currently yazi provide --cwd-file to get the cwd from a file. I thought it would be more intuitive to print the path to stdout directly, similiar to fzf. yazi --cwd-file=/dev/stdout doesn't works so I guess the implementation is different.

Hi, thanks for this awesome project!

Is it possible to specify only some keymaps in keymap.toml and make it override the said keymaps and make others default?
The use case is when I have to override only J and K keys so I have to only specify this in keymap.toml:

[manager]

keymap = [
    { on = [ "K" ], exec = "arrow -25", desc = "Move cursor up 25 lines" },
    { on = [ "J" ], exec = "arrow 25",  desc = "Move cursor down 25 lines" }
]

ranger, nnn and lf allows you to filter the current directory.

yazi already allows you to perform a recursive search using fd, but sometimes you just want to search for files within the current directory in real-time (search results are shown on every keypress, instantly).

log:

''''

The way image previews are positioned is kind of wrong:

They "bleed" out of their container a bit.

This article assumes that you have already used Yazi and are familiar with most of its features.

Yazi has undergone significant optimizations to enhance user experience. It is designed entirely as an async program, handling all time-consuming tasks (I/O and CPU) as async tasks in a non-blocking, event-driven manner.

Tokio

Internally, Yazi uses Tokio as its async runtime: hold on! Tokio's async may not be "truly async" as you might perceive it!

Uh, okay. From an application-layer perspective, it indeed is async; however, from a system-level view, there are possibly better solutions.

But! This is not the current performance bottleneck for Yazi. Considering Yazi is a TUI app, unlike CLI programs like ls and eza that need to output all files immediately, Yazi has more optimization opportunities at the application-layer:

• For large directories (e.g., 100,000 files), Yazi uses chunked loading, which is unmatched by ls and eza since they must load everything at once.
• Yazi also preloads directory file lists in the background, an optimization that ls and eza do not possess.

I must express my gratitude to Tokio for providing an excellent and convenient way to realize these application-layer optimizations.

I believe that the benefits brought by these application-level optimizations are more noticeable compared to switching to solutions like io_uring. But I'm open to this and welcome any constructive PR.

Here is a relevant discussion on Reddit: https://www.reddit.com/r/rust/comments/16fxr58/comment/k066gmh/

Pre-Loading

Preloaders are part of Yazi's concurrent plugin system, and the entire pre-loading process is asynchronous and spans multiple threads. This means that preloaders can handle not only expensive IO tasks but also CPU-bound tasks! Here are some built-in preloaders in Yazi:

• Mimetype: The baseline. Yazi uses the file's mime-type as a reference for tasks such as opening, previewing, and style rendering, and internally utilizes file(1) to obtain the file's mime-type. For better performance, Yazi computes them for files of an entire page, rather than for each file individually, and the entire process is chunked to minimize response latency.
• Image: To accelerate image previews, Yazi uses a 2-pass process for image files. The first pass is preprocessing, which downscales the image based on user-set max_width/max_height and generates a compressed lossy image as a cache file, significantly reducing file size. The second pass occurs when the user actually switches to the file and downscales it again to fit the terminal size.
• Video: To speed up video previews, Yazi pre-converts them into images and goes through the first pass of image processing. When the user needs to display the video, it goes the same second pass.
• PDF: Similar to video.
• Directory size: Yazi lazily calculates the directory size only when the user sets sorting by file size, as it's a time-consuming operation.

Note: Except for size, all of these are paged, meaning that when you are on the first page, only the first few files will be pre-loaded.

For example, if your directory has 1000 files, your terminal height is 10, and you are on the second page, only files 11 to 20 will be processed. This greatly saves resources.

Discardable Tasks

Every preview task is discardable. When you navigate between files quickly and the previous file's triggered preview task is still not finished, it will be discarded directly, initiating a new task. This promotes resource utilization:

• For I/O tasks like loading directory lists, Tokio's abort is used;
• For CPU tasks like code highlighting, an Atomic is used to store a ticket, and it checks if the value changes on each line code highlight. If it changes, indicates that the current context has changed, and the entire highlighting task is discarded.
• For I/O and CPU tasks like previewer/preloader plugins, with Lua, Yazi can check whether these tasks are canceled when a specific number of CPU instructions. If canceled, it interrupts the execution of the Lua script immediately, avoiding wasting more I/O and CPU resources.

Code Highlighting

Yazi has built-in code highlighting and keeps it to a minimum for all text files: if your terminal height is 10, only the first 10 lines of the file are read and highlighted.

Other file managers that rely on external programs like bat need to wait for bat to finish highlighting the entire file before displaying only the first 10 lines.

In cases like JSON that require external program jq, Yazi kills jq directly after reading the first 10 lines to avoid unnecessary resource consumption.

Since code highlighting is a CPU-bound task, it is distributed among multiple blocking threads, managed through Tokio's spawn_blocking, and is also discardable.

Image Preview

Yazi not only has built-in code highlighting but also includes image decoding and downscaling - there is likely nothing faster than having it directly built-in. It is also distributed among multiple threads and is discardable.

Besides being fast, Yazi's built-in Kitty graphics protocol, Inline images protocol, and Sixel graphics format allow Yazi to finely control when to display or hide images.

This ensures that in Yazi, there won't be issues, like images stacking on top of each other, or image escape code breaking the entire screen, when navigating through images quickly, as stdout is locked while outputting these escape codes. This locking happens after all image data is prepared, so it has no impact on performance.

Yazi even supports partially erasing content in preview images, which is useful for pop-up components (Input, Select). The image won't overlap the input, and when the pop-up disappears, Yazi redraws the image to complete the erased portion automatically.

Async Task Scheduling

In Yazi, tasks are prioritized based on their severity automatically. Yazi categorizes tasks into two types:

• Macro tasks: Large and heavy tasks, such as copying large files, typically taking a long time to complete.
• Micro tasks: Small and urgent tasks, such as fetching file mime-type, pre-loading images, calculating directory size, and so on.

This is similar to having big and small cores in a CPU; when the big cores are idle, they help with the micro tasks. Yazi defaults to starting 5 micro workers and 10 macro workers, and these numbers can be configured by the user!

In addition, Yazi introduces a priority scheduling mechanism. Each task has 3 priority levels: low, normal, and high. High-priority tasks can preempt low-priority tasks, applying to both micro and macro tasks. This increases task concurrency, slowing down HOL blocking caused by queuing execution of sudden requests.

For complex tasks like file copying, a combination of micro and macro approaches is employed. Micro is used to gather a list of all files to be copied recursively, allowing users to see the number of tasks and their sizes in advance. Macro, on the other hand, handles the actual copying process.

The advantage of task scheduling extends beyond providing ample concurrency for I/O and CPU resources; it also indirectly mitigates the depletion of system resources (such as file handles and CPU) due to sudden task surges.

Other optimizations

The above optimizations are the most noticeable to users, but behind the scenes, Yazi has also done many other optimizations. Include but are not limited to:

• The re-implemented highly optimized natural sorting algorithm is ~6 times faster than the natord that eza uses in case-insensitive sorting.
• Yazi caches the directory state that has already been read, avoiding any unnecessary IO operations.
• When a file in a directory changes, it only updates the changed files rather than re-reading the entire directory list.
• Merges multiple renders triggered by multiple commands into a single render, avoiding unnecessary CPU consumption.
• Frequent updates to components, such as progress bars, are rendered independently, which is no cost compared to a complete render.
• The entire plugin system is designed with an asynchronous-first philosophy to avoid blocking the main thread with time-consuming tasks.

TODO

I'll find time to continue writing.

I have to move the cursor between files to update the preview.

You call it "Blazing Fast", but do not show benchmarks or comparisons to other terminal file managers.

Some brief design questions:

• How will you ensure stuff works, ie to limit the scope, as you seem to integrate all functionality for what I believe is reasonably optimal performance?
• "Vim-like Input component, and Select component" is also very open-ended, since vim has a lot of functionality.

Some brief comments on README:

task priority assignment

Internal one or also by the Kernel scheduler? Use "internal task priority assignment", if you dont't use sched_* class functions ie on Linux etc.

All I/O operations are asynchronous

Are they using blocking syscalls or non-blocking ones (io_uring)? Would sounds nicer, if you mention asynchronous executed and using non-blocking syscalls, if available.

pre-caching mechanism

How much additionally memory does this use? Is this configurable? Overall memory consumption would be also nice to know and track to estimate what kind of low(er) end devices can be used with yazi.

I use the platform is xorg(dwm), why yazi occur such fail message.

IIUC, the preview method is hard-coded. I can use TERM=foot yazi to enable sixel preview but this is ugly. It's better to detect supported preview method or allow setting it in the config file.

Like #51 (comment) said, the current behavior of . only works locally (directory-specific).

As a contrast, the behavior of zh in joshuto can toggle whether to show hidden files globally as shown in a demostration.

Hi!

I was waiting for the windows release, thanks for making that happen!

I have a couple issues/question however - I have neither file preview (regardless of file extension - tested on txt, nix, json, md, and ini) nor file editing.

Config:

• Win10, latest WindowsTerminal for emulator, and pwsh for shell
• yazi installed via scoop (but the problem is present on a standalone executable)
• tools like vim, jq, fd, fzf, and ripgrep are present in $PATH

yazi is run with the default config - by the way, where is its config folder under windows?

Setting $env:EDITOR does not bring back file editing upon hitting enter.

Cheers!

sry for yet another report but that's because I like the program :)

Usually when I hit Ctrl-Z, it sends the program in background (it sends SIGSTOP), I go back to a shell prompt, I can run a few commands and then I can resume the program by typing fg.
Hitting Ctrl-Zdoes nothing with 0.1.4 , and it is not mapped in my ~/.config/yazi/keymap.toml .

I would like Ctrl-Z to pause, which may imply for yazi to react to the STOP signal

If I have for example this

[opener]
browser = [
	{ exec = 'chromium "$@"', display_name = "Open in Chromium" },
]

[open]
rules = [
	{ name = "*.html", use = ["browser"] },
]

and want to open a file called test.HTML it won't work. But it will work for test.html. Is there an easy way around that?

Edit: it seems to also apply to the theme icons.

great job!
i read source and know rename command can do bulk_rename, and config is opener in yazi.toml, but how to pass args in exec command?
in windows , config like this is useless. and i have no idea on how to bulk rename . please help me

[opener]
text = [
	{ exec = 'nvim "$@"', block = true },   // useless
       { exec = 'nvim "%*"', block = true },    // useless
]

Can rg search preview like this in the nvim plugin, or can it jump directly to fzf, like using the rg | fzf command on the command line

for instance I was navigating a folder with typescript files (*.ts) and yazi 0.1.3 can't preview them ?

I've found no method in the docs (https://github.com/sxyazi/yazi/blob/main/config/docs/yazi.md). By the way I think it would best for the "docs" folder to live at the top-level/root of the repository otherwise it feels like there are no docs

I would like to be able to do yazi ~/Downloads and have yazi open with ~/Downloads as the current folder similar to what ranger can do ( ranger ~/Downloads works)

Requires raphamorim/rio#38

Using Arch and have mupdf to open/view pdf files. What's needed to get pdf previews to work in yazi?

yazi 0.1.4 on archlinux, no custom config
alacritty terminal with light background
open yazi and type g, the keymap prompt text is unrecognizable:

Both unar and poppler are available in scoop - since the recommendation to install yazi points to scoop, we might as well install other stuff via the same tool.

I do not have file preview at all (#115), so I can not confirm that these scoop-installed tools work well with scoop-installed yazi.

https://github.com/helix-editor/nucleo

As stated in the README:

nucleo is a highly performant fuzzy matcher written in rust. It aims to fill the same use case as fzf and skim. Compared to fzf nucleo has a significantly faster matching algorithm. This mainly makes a difference when matching patterns with low selectivity on many items.

my picture name is:
1ce2dcf7efb043fbe85800eeb9fda11d6f3ac93a4987a236beaced8bb18d2190.jpg

when I rename it, i can't see the fullname on rename Input field. so,when i just delet what i can see and input a new name, it will remain some old string from the old fullname.

add the keymap view

As an file-manage, the keymap is important, and let the user to learn about the keymap is more important. So if can use a keymap to see the keymap, the more people should use yazi.

If use the key ? to see the keymap view ,like this:

Version: 8fd3d15

When I try to open a folder, it shows this message. What does it mean?

I'm testing on macOS with iTerm and I can see the image preview:

❯ echo $TERM, $TERM_PROGRAM, $XDG_SESSION_TYPE
xterm-256color, iTerm.app,

However, when attaching to a tmux session, I can no longer see an image preview:

In tmux the term is set as follows

❯ echo $TERM, $TERM_PROGRAM, $XDG_SESSION_TYPE
screen-256color, tmux,

however, even when setting those to the previous values, there is still no preview

❯ export TERM=xterm-256color
❯ export TERM_PROGRAM=iTerm.app
❯ echo $TERM, $TERM_PROGRAM, $XDG_SESSION_TYPE
xterm-256color, iTerm.app,
❯ yazi # still no preview

i dont know if is a error or is a possible feature to you implement, but will be great has this working.

I know users can create their own scoop bucket, but it would be great if yazi can be added to https://github.com/ScoopInstaller/Main.

As I was encouraged to do so, while using Yazi I thought of other points which could be useful:

1.) Possibly even be called a bug: Currently Yazi does not honor the full selection made when copying or cutting. Similar to #84 , only the files (selection) of the current folder are included. This is not very intuitive in my opinion. Why should my selection be limited to my current location?

2.) In addition, a display of the number of currently selected/cut/copied files would be nice. The solution of LF could offer inspiration for this. Here the number is displayed in a small field and via colorcode whether the display indicates marked, copied ect.

Examples:

5 selected files

5 yanked files

3.) Display Name in Keymap. As already described this would contribute strongly to the overview. Is this possibly related to #79?

4.) The possibility for more information about the files. A file manager should provide a quick overview of my file system. For this it can be helpful to be able to capture appropriate metadata, such as size, access rights, creation date and last modification at a glance.

xfce-terminal now supports sixel. Opening this issue as requested on reddit.

references:

• https://www.arewesixelyet.com/#xfce-terminal
• https://gitlab.xfce.org/apps/xfce4-terminal/-/commit/493a7a54b437df9419847b29fe94eae671816c09
• https://old.reddit.com/r/rust/comments/16fxr58/meet_yazi_blazing_fast_terminal_file_manager/k065x8r/

Sometimes, for instance when viewing HTML files, there can be extremely long single lines in the file. In such cases, the automatic line wrapping feature can be helpful. Additionally, to aid this functionality, the preview feature may benefit from having line numbers.

Would it be possible to add multiple openers for a rule? For example with

[opener]
text = [
	{ exec = 'nano "$1"', block = true, display_name = "Edit with nano" },
]
browser = [
	{ exec = 'chromium "$@"', display_name = "Open in Chromium" },
]

[open]
rules = [
	{ name = "*.html", use = ["browser", "text"] },
]

it would show

Open in Chromium
Edit with nano

as options.

This would reduce the overhead of duplicating entries.

Hello. Config files don't load by default.

I download config files from preset and put them into ~/.config/yazi/. I change to show hidden files to true show_hidden = true. But after restart application they don't load. So my home folder doesn't show hidden files with .. Where can be problem?

Also in config, how I can change bat to use --theme="gruvbox-light"? I write syntect_theme = "gruvbox-light" in theme.toml but it doesn't seems to work.

Currently, when opening a text file, Yazi just seems to try to use vim to open it. It would be great if instead it was referring to the EDITOR environment variable and use that value instead, with a fallback of vim if the variable is not set.

IIUC, yazi doesn't support config files in /etc because dirs is used, as all other rust cli apps. Could you please support that on Linux?

Bugs

• Exit selection mode on leave
• Exit selection mode on yank
• Trigger Refresh manually when rename, create, in case notify-rs doesn't update in time
• Precache n+1 pages of mimetype instead of n for the better experience
• Image preview on node-pty based terminal, like Hyper canary and VSCode

Features

• Forward / Backward
  No request

• Find next/previous file (not the Search feature that's already existing)
  Requested by @teto, #81

• Custom preloader / previewer
  Requested by @Neurognostic, #182

• Filter files in real-time
  Requested by @musjj, #137

• Vim-like H/M/L for scrolling (:help H in Vim for more info)
  Requested by @TD-Sky

• Make the preview scrollable
  Requested by cg00@Discord

• File chooser API used for Neovim plugin
  Requested by @Eric-Song-Nop

• Git integration
  Requested by @g-plane, @cap153, @cxwx

• Copy file path
  Requested by @Gajus84, #70

• Mouse actions binding in keymap.toml
  Requested by @Gajus84, #70

• macOS-like file tag
  Requested by @sxyazi

• Transparent images support
  No request

• GIFs images support
  Requested by @JustinBacher, #1195

• Customizable scroll offset and popup position improvement
  No request

• Better borders style
  Requested by @sxyazi

• Case-insensitive sorting
  No request

• Emacs readline keybindings for Input component
  Requested by @teto

• Auto-completion for Input component
  Requested by @maxzinkus

• Custom manager layout
  Requested by @KeqiZeng, #71

• Sort files naturally
  Requested by @asim215

• Show all binding keymaps
  Requested by @hackers267, @maxzinkus, #79

• Show file size after the filename
  Requested by @sxzz, #88 (comment)

• Display of the number of currently selected/cut/copied files
  Requested by @Gajus84, #85

• A floating window to glance at more information about this file (mime-type, atime/ctime/mtime, previewer, preloaders, EXIF for images/videos, etc.)
  Requested by @Gajus84, @teto, #85, #831 (comment)

• Re-previewing in real-time when the file content changes
  Requested by @otakutyrant, #129

• Shell command history
  Requested by @mbirth, #51 (comment)

• Sorting by file type
  Requested by @v01dnu11, #51 (comment)

• Hide specified files or directories
  Requested by @5ouma, #51 (comment)

• Shell completion
  Requested by @MinaMatta98, #420

• Remote file management
  Requested by @Xuanwo, #434, #611

• Archives as directories
  Requested by @git-rz, #417

• Auto-complete supports smart case
  Requested by @RioNight, #547

• Natural sorting supports Hungarian letters
  Requested by @og900aero, #616

• Group tasks in Task Manager by "Running"/"Failed"
  Requested by @teto, #1105

• Dual panel
  Requested by @c02y, @vladimir-salvador, #51 (comment), #1294

This problem is very strange, and will only happen the first time, when you can not see file list in the current path, press the left arrow key, then press the right arrow key, the file in the current path can be saw again .

After that, I repeated the first operation (jump fzf to search and select a file in the same path). After the selection, I can see file list in the path.

I'm running yazi on NixOS inside Alacritty, and the image previews are not working.

I also tried opening a shell with uberezugpp available and then starting alacritty and yazi from there, but this doesn't seemt o make a difference.

Any tips on getting this working?

Hi, first of all thanks for such a good project.

I have tried to migrate from ranger to yazi recently, It's super fast and has many features out of box. But I think the preview area a bit small for me. If the user can define the column_ratio their own just like in joshuto, it will be very great I think. It maybe looks like:

Thank you again for what you've done for yazi!

Thank you first for this great project. Yazi already includes many features out of the box, which fit my workflow.

One of them, copying filename, path etc. however does not work in my Hyprland system so far. I suspect that wl-copy is not recognized or called.

Furthermore it seems to be currently not possible to pass selected file(s) path(s) to the shell in a command? Analogous to the method in yazi.toml, this would greatly extend the flexibility of the inbuild shell.
Use case is e.g. adding files in Chezmoi by key command. Currently I "abuse" the interactiv opener for this.

Also, it would be nice to be able to assign mouse actions in keymap.toml as well. Even though a terminal program is primarily designed for keyboards, it would be nice to be able to use extra mouse keys as well. Also I could customize the scroll function. Currently I always skip three lines per scroll, which limits the usage a bit.

Please correct me if I'm mistaken, but it seems like Yazi is saving video thumbnails only for the current session. Depending on the amount of (video) files this can grow into a major bottleneck. Especially when using the Wrapper.

LF and Ueberzug++ are solving this by storing the generated thumbnails in the users tmp/cache directory and using those as a source (via the videos path afaik) before calling ffmpegthumbnailer again. That's ofc much quicker.

I believe that could be a good approach to follow by yazi too?

how i can change default file opener

Like project https://github.com/dundee/gdu, I think it's great to integrate with disk usage analyzer.

At least, adding the file/directory size and sort by size.

When searching, the top line shows "(search)", but not what the search term was.

This can be a bit confusing.

Would be good to show the term in the header, like (search: "searched-term").