Configuration is too convoluted

[Niceadam]

What system are you running Yazi on?

Linux Wayland

What terminal are you running Yazi in?

Kitty

ya env output

Yazi
    Version: 26.9.1 (Arch Linux 2026-09-04)
    Debug  : false
    Triple : x86_64-unknown-linux-gnu (linux-x86_64)
    Rustc  : 1.98.1 (48a229ce 2026-09-01)
    Backtrace: None

Ya
    Version: 26.9.1 (Arch Linux 2026-09-04)
    Debug  : false
    Triple : x86_64-unknown-linux-gnu (linux-x86_64)
    Rustc  : 1.98.1 (48a229ce 2026-09-01)

Config
    Init             : /home/niceadam/.config/yazi/init.lua (1293 chars)
    Yazi             : /home/niceadam/.config/yazi/yazi.toml (176 chars)
    Keymap           : /home/niceadam/.config/yazi/keymap.toml (867 chars)
    Theme            : /home/niceadam/.config/yazi/theme.toml (156 chars)
    VFS              : /home/niceadam/.config/yazi/vfs.toml (No such file or directory (os error 2))
    Package          : /home/niceadam/.config/yazi/package.toml (No such file or directory (os error 2))
    Dark/light flavor: ArcSwapAny("") / ArcSwapAny("")

Emulator
    TERM                : Some("xterm-kitty")
    TERM_PROGRAM        : None
    TERM_PROGRAM_VERSION: None
    Brand.from_env      : Some(Kitty)
    Emulator.probe      : Emulator { brand: Kitty, version: ArcSwapAny("kitty(0.49.2)"), csi_u: Some(0), kgp: true, kgp_shm: true, sixel: false, background: Some([7196, 6425, 5911]), color_scheme: Some(false), csi_16t: (10, 20), force_16t: false, osc_5522: true, cursor_blink: false, cursor_shape: Some(1), mux: None, probe: Probe { id: Id(0), completed: false }, started: false }

Adapter
    Drivers.matches: Kgp
    TERM.dimension : Dimension { cols: 94, rows: 50, width: 940, height: 1000 }

Desktop
    XDG_SESSION_TYPE           : Some("wayland")
    WAYLAND_DISPLAY            : Some("wayland-0")
    DISPLAY                    : Some(":0")
    NIRI_SOCKET                : None
    SWAYSOCK                   : None
    HYPRLAND_INSTANCE_SIGNATURE: None
    WAYFIRE_SOCKET             : None

SSH
    shared.in_ssh_connection: false

WSL
    WSL: false

Variables
    SHELL              : Some("/bin/fish")
    EDITOR             : Some("/usr/bin/helix")
    VISUAL             : Some("/usr/bin/helix")
    YAZI_FILE_ONE      : None
    YAZI_CONFIG_HOME   : None
    YAZI_ZOXIDE_OPTS   : None
    SSH_AUTH_SOCK      : None
    FZF_DEFAULT_OPTS   : Some("--info=inline")
    FZF_DEFAULT_COMMAND: Some("fd --type f --hidden")

Text Opener
    default     : Some(OpenerRuleArc(OpenerRule { id: Id(3), run: "${EDITOR:-vi} %s", block: true, orphan: false, desc: "$EDITOR", for: Unix, spread: true }))
    block-create: Some(OpenerRuleArc(OpenerRule { id: Id(3), run: "${EDITOR:-vi} %s", block: true, orphan: false, desc: "$EDITOR", for: Unix, spread: true }))
    block-rename: Some(OpenerRuleArc(OpenerRule { id: Id(3), run: "${EDITOR:-vi} %s", block: true, orphan: false, desc: "$EDITOR", for: Unix, spread: true }))

Multiplexers
    tmux version       : No such file or directory (os error 2)
    tmux build flags   : enable-sixel=Unknown
    ZELLIJ_SESSION_NAME: None
    Zellij version     : No such file or directory (os error 2)

Dependencies
    file          : 5.48
    ueberzugpp    : No such file or directory (os error 2)
    ffmpeg/ffprobe: 9.0.2 / 9.0.2
    pdftoppm      : 26.10.0
    magick        : 7.1.2-35
    fzf           : 0.74.5
    fd/fdfind     : 10.5.0 / No such file or directory (os error 2)
    rg            : 15.2.0
    chafa         : No such file or directory (os error 2)
    zoxide        : No such file or directory (os error 2)
    7zz/7z        : No such file or directory (os error 2) / 26.05
    resvg         : 0.49.0
    jq            : 1.8.2

Clipboard
    wl-copy/paste: 2.3.0 / 2.3.0
    xclip        : No such file or directory (os error 2)
    xsel         : No such file or directory (os error 2)

Routine
    `file -bL --mime-type`: text/plain

Describe the question

1. Out of all clis/tuis that I use, yazi has by far the most configuration files (keymap.toml, yazi.toml, init.lua, theme.toml, plugins). helix, kitty, umbriel... all have a single config file. Can't we have the same? (like config.toml)
2. I have a plugin thats 4 lines long, can't I somehow put it in init.lua without a seperate folder in plugins?
3. sometimes stuff go in init.lua, sometimes stuff go in yazi.toml. some stuff and not all, can be done in both. Can't we just have init.lua like neovim?
4. in neovim, I make a lua function, I bind a key to call that lua function. Here this can only be done with a plugin, that I have then call in a string in a toml file
5. session.lua? you init that as a built-in plugin in init.lua. extract.lua? thats different, you bind that as an opener in yazi.toml with a string that is actually a ya cli call that publishes some event.

I understand that the Lua API is changing and that some of this was done for optimization purposes. Unlike code nowadays, I usually modify the configs by hand but for yazi I've sort of just given up and just deal with some of the annoyances since I can't be bothered to do the digging needed to modify it. I love yazi and I will keep using it but are there any plans for making this more coherent?

Anything else?

No response

Checklist

• I have read all the documentation
• I have searched the existing discussions/issues

[sxyazi]

1. I don't see a problem with having multiple config files, to me it's clearer and easier to manage: if you want to change keybindings, go keymap.toml, if you want to change the theme, go theme.toml, everything else that's general goes in yazi.toml. As for init.lua, as its name implies, it's used for plugin initialization. If you don't use plugins, or your plugins don't need initialization at all, you don't need to touch init.lua. Another benefit is that actions like app:theme that reload the user theme, only need to reload theme.toml, rather than reloading the keybindings and general config or anything else along with it in the same single file, which is better for performance.

2. init.lua is usually only used for initialization, and the actual impl of a plugin is not placed directly in init.lua. That said, it doesn't mean you can't do that, and some APIs (such as ya.async and ya.sub) can already be used directly in init.lua now, and you can also dynamically register keybindings, previewers, spotters, fetchers, preloaders, open rules, opener rules, and so on in init.lua as well.

3. Yep, the ultimate goal is to allow users to configure anything in init.lua, but the classic TOML config won't be abandoned because of that since quite a few Yazi users aren't expert programmers or CS pros, they just enjoy tinkering with open-source tools like Yazi. Having an optional TOML, where most features can be adjusted through TOML config, is much less intimidating for them than Lua.

   There has been some progress on this so far:

   • feat: allow dynamic adjustment of layout ratio via rt.mgr.ratio #2964
   • feat: dynamic previewer Lua API #3891
   • feat: dynamic open/opener Lua API #3901
   • feat: dynamic Lua API for preloader, spotter, fetcher #4235
   • feat: dynamic keymap Lua API #4031
   • feat: new update methods to dynamic Lua plugin APIs #4389
   • feat: dynamic virtual filesystem Lua API #4338

   but still a lot of work to do. I'd like to point out that Yazi != Neovim, don't expect them to be the same. Things that seem trivial in Neovim may take considerable effort to implement in Yazi, mainly because their architectures are vastly different (Yazi uses a multi-threaded, async architecture, while Neovim uses a single-threaded, sync one), and accepting the performance advantages of this architecture also means accepting certain limitations. On the other hand, Yazi is much more niche than Neovim and many of its users don't know programming, which means far fewer contributors are able to contribute to it in the long term, and currently I'm its only maintainer, so good things can take time. Dynamic configuration #2047 has more info about why it is difficult to implement.

4. Again, this is still the architectural limitation mentioned above, and let km.mgr.rules:insert(...) accept function as arg #4297 has more discussion about it. If you have any ideas on how to resolve this puzzle, do share!

5. session.lua and extract.lua are the same in that both need to be initialized, except that extract.lua is already initialized by Yazi, so you don't need to initialize it yourself. Initializing extract.lua has almost no side effects, so it was built in, whereas initializing session.lua means enabling yank sync, which not every user needs or wants. The only difference here is perhaps that extract.lua provides an extract event of the same name, which you can use anywhere (whether in Lua or TOML), whereas session.lua doesn't provide any events.