You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please describe the problem you're trying to solve
For a long time, Yazi has been designed as a TUI application. But as Yazi continues to evolve, new needs arise, and these needs can be more efficiently met as a CLI program.
When Yazi starts, it needs to read all configuration files, check and merge these configurations, and detect the operating system and terminal type for correct image rendering. These are time-consuming operations, especially detecting the terminal type, which requires sending CSI sequences to the terminal and waiting for a response.
This requires Yazi to have the ability to read from stdin. But this is not suitable when integrating externally, such as calling Yazi in a shell script to perform the following tasks:
ya send: Ability to communicate with DDS to address Ability to change yazi CWD from external process #891. After changing the shell's current working directory, send a message to Yazi to notify the ongoing Yazi instance to synchronize the cwd.
ya cp: A faster alternative to cp with the powerful async task scheduling system, providing a progress bar and more beautiful. This is part of future plans.
ya mv: A faster alternative to mv with the powerful async task scheduling system, providing a progress bar and more beautiful. This is part of future plans.
ya ls: A faster and more beautiful alternative to ls. This is part of future plans.
ya colors: Address Produce LS_COLORS output when invoked with special flag #852, output Yazi themes as LS_COLORS for a more readable way to use these colors in the shell through configuring the Yazi theme. It still needs to read the configuration file, but it can be minimized and lazily loaded only when this command is called, rather than at program startup, and only the theme configuration is read. Note that I am still considering whether to implement it; it may ultimately not become a reality.
ya plugin / ya theme: Providing plugins, theme management functionality, such as installation, updating, uninstalling, etc., is also a feature I am still considering.
The new CLI program will use ya as its name because it is short enough and will be more convenient when executing commands like ya cp or ya mv.
The only issue might be potential name conflicts with shell wrappers, but I don't think this is a big problem - I renamed the shell wrapper to yy last month, and it does not interfere with existing users since shell functions should always take precedence over CLI programs.
For new users who want to use the new CLI, I will note in the documentation that it may conflict with the name of the shell wrapper they set before.
Would you be willing to contribute this feature?
Yes, I'll give it a shot
Describe the solution you'd like
.
Additional context
No response
The text was updated successfully, but these errors were encountered:
ya cp: A faster alternative to cp with the powerful async task scheduling system, providing a progress bar and more beautiful. This is part of future plans.
ya mv: A faster alternative to mv with the powerful async task scheduling system, providing a progress bar and more beautiful. This is part of future plans.
Please describe the problem you're trying to solve
For a long time, Yazi has been designed as a TUI application. But as Yazi continues to evolve, new needs arise, and these needs can be more efficiently met as a CLI program.
When Yazi starts, it needs to read all configuration files, check and merge these configurations, and detect the operating system and terminal type for correct image rendering. These are time-consuming operations, especially detecting the terminal type, which requires sending CSI sequences to the terminal and waiting for a response.
This requires Yazi to have the ability to read from
stdin
. But this is not suitable when integrating externally, such as calling Yazi in a shell script to perform the following tasks:ya send
: Ability to communicate with DDS to address Ability to change yazi CWD from external process #891. After changing the shell's current working directory, send a message to Yazi to notify the ongoing Yazi instance to synchronize the cwd.ya cp
: A faster alternative tocp
with the powerful async task scheduling system, providing a progress bar and more beautiful. This is part of future plans.ya mv
: A faster alternative tomv
with the powerful async task scheduling system, providing a progress bar and more beautiful. This is part of future plans.ya ls
: A faster and more beautiful alternative tols
. This is part of future plans.ya colors
: Address Produce LS_COLORS output when invoked with special flag #852, output Yazi themes as LS_COLORS for a more readable way to use these colors in the shell through configuring the Yazi theme. It still needs to read the configuration file, but it can be minimized and lazily loaded only when this command is called, rather than at program startup, and only the theme configuration is read. Note that I am still considering whether to implement it; it may ultimately not become a reality.ya plugin
/ya theme
: Providing plugins, theme management functionality, such as installation, updating, uninstalling, etc., is also a feature I am still considering.The new CLI program will use
ya
as its name because it is short enough and will be more convenient when executing commands likeya cp
orya mv
.The only issue might be potential name conflicts with shell wrappers, but I don't think this is a big problem - I renamed the shell wrapper to
yy
last month, and it does not interfere with existing users since shell functions should always take precedence over CLI programs.For new users who want to use the new CLI, I will note in the documentation that it may conflict with the name of the shell wrapper they set before.
Would you be willing to contribute this feature?
Describe the solution you'd like
.
Additional context
No response
The text was updated successfully, but these errors were encountered: