Dynamic configuration

[sxyazi]

This issue tracks and explores the possibility of adding dynamic configuration support in Yazi.

The goal is to allow part or all of the configuration to be applied dynamically either through command-line arguments, environment variables before Yazi starts, or via Lua API, commands while Yazi is running, without modifying the toml configuration files.

For optimal performance, Yazi currently reads and parses the configuration file only once at startup, marking the parsed configuration as statically read-only.

This allows the configuration to be safely shared across multiple threads (&'static), and also enables optimizations like storing a reference to the icon configuration in each File structure:

yazi/yazi-fs/src/file.rs

Line 14 in c1048de

pub icon: SyncCell<IconCache>,

This avoids redundant icon matching for the same file when rendering the file list, since the reference is just a pointer and doesn't require including the full icon information, thus saving memory.

Due to the immutability of the configuration, Yazi only serializes the configuration into Lua once at startup, supporting dynamic configuration would also mean re-serializing the configuration whenever it changes, and serialization is a relatively expensive operation, which could lead to performance degradation.

Dynamic configuration was deliberately omitted from Yazi's original design, and implementing it would require substantial changes to the architecture, likely at the cost of performance and increased project complexity.

Therefore, this feature may ultimately not be implemented unless the following obstacles can be addressed:

• How should it be supported? Command-line arguments, environment variables, Lua API, or commands? In what format (TOML, JSON, or custom format)?
• Which configurations need to be dynamic? yazi.toml, keymap.toml, theme.toml?
• What would its behavior be like? Would it override or append to the existing configuration? What would the user interface look like when using it?
• How can thread safety be ensured with dynamic configurations? Would the existing optimizations be compromised?
• How can changes to the configuration be efficiently synchronized with Lua?
• What impact would it have on performance and project complexity? Is the cost worth it?
• Is there anyone willing to invest time and effort into pushing this feature to completion?